DeNA における AWS とオンプレミスのハイブリッドクラウド運用

こんにちは。元 IT 基盤部の安武です。

実は、3 月時点で IT 基盤部から現在所属する Japan リージョン事業本部に異動していたのですが、今日は元インフラエンジニアとして、DeNA における AWS の活用事例を紹介します。

 

DeNA では以前からデータセンターと契約して、オンプレミスによるサーバインフラ環境を構築してきましたが、最近では案件によって AWS や GCP といったパブリッククラウドを利用する事例も出てきました。

さて、それぞれの環境でサーバ作業を行う際、社内で共通の踏み台サーバを経由してログインすることになっています。

案件を担当する開発者は、担当の環境にログインして作業できれば十分ですが、複数案件を担当するインフラメンバーの場合、AWS とオンプレミスを含む複数環境にログインすることもあります。

しかし、異なる環境で作業するためにログインし直したり、端末を複数起動することは、運用作業者にとっては負担になります。

そこで導入したのが、AWS VPC VPN による AWS - オンプレ間接続と、VPC Peering による AWS VPC 間の接続です。


大まかな全体構成を下図に示しました。

図のように、オンプレミスと個々の AWS VPC との間は VPN 接続し、更に VPC 間で VPC Peering によって相互接続しています。

この図の詳細に踏み込む前に、AWS VPC VPN と VPC Peering について、簡単に説明しておきます。

 

AWS VPC VPN による AWS - オンプレ間接続

AWS VPC の VPN 接続にはいくつかオプションがありますが、私たちは AWS ハードウェア VPN を選びました。これにより、オンプレミスの拠点と AWS の VPC との間を IPsec-VPN で接続することができます。

AWS マネジメントコンソール上の作業手順は、ドキュメント「VPC へのハードウェア仮想プライベートゲートウェイの追加」に示されています。概略のみ以下に記します:

  1. Customer Gateway を新規作成する

  2. Virtual Private Gateway を新規作成し、VPN 接続したい VPC に Attach する

  3. VPN Connection を新規作成する

  4. ルートテーブルを設定する

  5. ネットワーク機器側で Customer Gateway の設定を行う

DeNA では、1 - 4 の工程はスクリプト化しており、現在はマネジメントコンソール上で作業する必要はなくなりました。

 

VPC Peering による VPC 間接続

VPC Peering を利用すると、異なる AWS アカウントの VPC 間でトラフィックをルーティングし、同一のネットワーク内にいるかのように通信することができます。

ただし、Peering する VPC 同士は同一リージョンでなければならず、CIDR が重複してはならないなど、色々な制約があります。利用する際は、ドキュメント「VPC ピア機能の制限事項」 を熟読することをお薦めします。

設定手順は、ドキュメント「VPC ピア接続の操作」に従います。以下、概略を記します。

前提として、私たちのインフラ環境の場合、上図で「インフラ環境」と記した VPC をハブとするスター型の構成を取っています。

  1. 上図の「サービスC」など、個々のサービス環境の VPC で VPC Peering Connection を作成し、接続先の VPC として、「インフラ環境」の AWS Account ID と VPC ID を設定する

  2. 「インフラ環境」の AWS アカウントで、VPC ピア接続リクエストを承認する

  3. 「インフラ環境」の VPC Peering のルートテーブルを更新し、新規に Peering した VPC へのルーティング設定を行う

こちらの作業も、スクリプトによって機械化しています

 

ネットワーク障害の影響を減らすために

導入時に懸念されたのは、VPN 接続に障害が発生するというシナリオです。

特に、DeNA のサーバ環境では全体的に名前解決に MyDNS を利用しています。MyDNS のマスターはオンプレミス環境にありますが、AWS 環境からオンプレミスの MyDNS を直接参照すると、VPN 障害時に致命的な影響が出ることが予想されました。

そこで、上の図のように、MyDNS を AWS 環境にレプリケーションさせ、AWS 環境では AWS 環境の MyDNS を参照する構成を取りました。

また、監視サーバは当初、オンプレミスのものを共用のものとして使っていましたが、VPN 導入後に何度か VPN 接続が不安定になることがあり、その度に AWS 環境の全サーバでアラートが発生するという事象があったため、AWS 環境にも監視サーバを用意することになりました。

 

導入の効果と費用について

VPN + VPC Peering を導入したことで、踏み台となるオンプレミスの「インフラ環境」から各サービス環境へのアクセスが可能になりました。

これにより、例えばオンプレの作業環境から EC2 インスタンスに chef を実行できるようになるなど、作業効率が向上しました。また、MyDNS や監視サーバなどの共通コンポーネントを集約したことで、個別のサービス環境の構築に必要なコンポーネントを減らすこともできました。

一方の費用についてですが、導入前と比較して、VPN 接続1本あたり 0.05 USD/時 + VPN 経路上のデータ転送料金がアドオンで掛かることになります。

VPN 経路上で大量のトラフィックを流すようなことがなければ、費用的なインパクトは出ないのではないかと思います。

 

まとめ

DeNA インフラで行っている、オンプレミスと AWS のハイブリッドクラウドの事例を紹介しました。

オンプレミスか、パブリッククラウドかを選択するケースなどで、何かの参考になれば幸いです。

 

参考