PLAIDEngineer Blog
エンジニア積極採用中

AWSとGCPでマルチクラウドインフラを構築した話とそのポイント

Naohiko Takemura

Posted on

ごきげんよう。プレイドの@tik-sonと申します。
みなさんはクラウドプラットフォームを利用していますか？

弊社のKARTEは

  • 秒間3000イベントをリアルタイムで解析
  • 累計解析ユーザがリリースから2年で12.5億
    https://karte.io/infographic/2017.html

という規模のサービスになっています。
そこで動いているインフラもそれなりに大規模になっており、インフラをいかに改善していくかが事業進捗に大きく関わってきます。

そのインフラを改善する試みとして半年ぐらい前から、AWSとGCPの２つのクラウドプラットフォームを組み合わせ、マルチクラウドインフラとして利用しています。
PLAID Enginner Blogでは複数回に渡ってマルチクラウドインフラを作る上で試行錯誤したポイントなどを紹介していこうと思います。
今回は初回ということで概要部分について記載し、次回以降のエントリーで深掘りをしていきます。
興味を持たれた方は本ブログをブックマーク等をしていただけば幸いです。

目次

  • マルチクラウドインフラとは？
  • なぜマルチクラウドインフラを作るのか？
  • マルチクラウドインフラの構成
  • マルチクラウドインフラへの移行手順
  • まとめ
  • 最後に

マルチクラウドインフラとは？

私達がお話するマルチクラウドインフラとは、
複数のクラウドプラットフォームを組み合わせ、それぞれのサーバが相互通信でき、あたかも１つのプラットフォームのように稼働させることができるインフラのことです。
イメージにすると以下の図のようになります。

なぜマルチクラウドインフラを作るのか？

可用性の向上

各クラウドプラットフォームではそれぞれのサービスごとにSLAが定義されていますが、100%の稼働を保証するものではありません。
CloudHarmonyというサービスで過去の稼働率を確認することが出来るのですが、例えば、EC2、GCEにおいてもDowntimeはそこそこ発生しているようです。

また、各クラウドプラットフォーム内にてMultiAZやMultiRegionの構成を取ることで可用性を高めることは可能ですが、クラウドプラットフォームの共通部分で問題が起きてしまうと、MultiAZやMultiRegion構成を取っていてもサービスダウンを避けることは出来ません。
実際、GCPでLoadBalancerがリクエストをサーバにフォワード出来ず、502のreponseを返すという障害が発生したこともあります。
複数の異なるクラウドプラットフォームで稼働させることは、単一クラウドプラットフォームの障害の影響を抑えることができ、可用性を高めることができます。

パフォーマンスの向上

AWS、GCP共に様々な特色のサービスを提供しています。
それぞれのサービスには得意、不得意な部分があり、適材適所で使うことでアプリケーションのパフォーマンスを向上させることができます。
KARTEにおいても処理の一部をGCPのCloud Bigtableに置き換えたことにより、パフォーマンスが大きく改善しました。

ただ、「AWSのEC2からGCPのCloud Bigtableを利用する」といったようなクラウドプラットフォームをまたいでサービスを利用する際は、以下の要素がパフォーマンスを悪化させることがあり、無視することはできません。

  • 同じクラウドプラットフォーム内からの通信に比べて Latencyが大きくなる
  • 各クラウドプラットフォーム管理外のネットワークが間に挟まってしまうので、問題が起きやすくなる

当然ですが、Cloud BigtableのSLAにも (c) errors: (i) caused by factors outside of Google's reasonable control; というようにGoogleのコントロール外の部分でのエラーはSLA適用外と明記されています。
https://cloud.google.com/bigtable/sla

サーバを手軽にそれぞれのプラットフォームに配置できる状態を作り、利用サービスの近くにサーバを配置させることで、各サービスの恩恵をより多く受け、アプリケーションのパフォーマンスを向上させることができます。

コストの低減

各クラウドプラットフォームのサービスを適材適所に利用するだけでコストの低減が期待できるように思えますが、何も考えずに他クラウドプラットフォームのサービスを使用してしまうと、パフォーマンスは向上はする一方で、膨大なコストがかかってしまうことがあります。
Cloud Bigtableを例に考えてみます。
Cloud BigtableはGCPのサービスですが、もちろんAWSからも利用することができます。しかしAWS側から利用するとなると、インターネット経由でCloud Bigtableと通信することになるので、以下の図のように データ転送コストが有料になってしまいます。

  • EC2でのCloud Bigtableからのread(①)はCloud BigtableのInternet EgressとしてGCP側で課金
  • EC2からCloud Bigtableへのwrite(②)はEC2のInternet EgressとしてAWS側で課金
  • Cloud Bigtableと同RegionのGCEであればread(③)、write(④)共に無料

少量のデータを扱う際には対して気にならないかもしれませんが、大量のデータを扱うサービスは注意が必要です。請求を見て寿命が縮むことになります。
実際に私達もCloud Bigtableの請求を見て寿命が縮んだ経験があります。
私達がCloud Bigtableを導入しようと検証していた際にはインターネット経由のデータ転送コストが 無料 だったのですが、あるタイミングから有料に変更になり、気がついた時には サービス使用量全体の約30% をCloud Bigtableデータ転送コストが占めていたこともありました。。コストのアラートは適切に設定しておくことをおすすめします。
パフォーマンスの話と同様にコストにおいても、サーバを手軽にそれぞれのプラットフォームに配置できる状態を作り、利用サービスの近くにサーバを配置させることは重要です。

そこに新しくて良い技術があったから

新しいサービス/技術はどんどん触りたいし、良いものはどんどん導入したいというモチベーションが煮えたぎっていました。**「そこに新しくて良い技術があったから」**というのはプレイドのエンジニア文化として根付いています。

マルチクラウドインフラの構成

上記のモチベーションを元に作ってみたマルチクラウドインフラの構成概要図を掲載します。
詳細は別のエントリーでお話することになると思いますが、ポイントとしては以下の通りです。

  • AWS、GCPのPrivateNetworkをVPNで接続する。
  • Cloud BigtableやBigqueryなどGCPのサービスを多く使うサーバは主にGCPで、DynamoDBなどAWSのサービスを多く使うサーバは主にAWSで稼働させる。
  • 特定のクラウドプラットフォームで何か問題があっても片方のクラウドプラットフォームで動くようにする。

また、運用周りのツール/サービスは基本的マルチクラウド対応しているものを利用しています。以下に一部を記載します。

用途 ツール名
インフラの構成管理 Terraform
マシンイメージの作成 Packer
マシンイメージのテスト Serverspec
メトリックの監視/アラート Datadog

マルチクラウドインフラへの移行手順

KARTEは元々はAWS上でのみで稼働していたので、既存のAWSで作っていた仕組みをベースに以下のステップでマルチクラウドインフラへと移行していきました。
ちなみに移行作業はKARTE利用ユーザに影響が出ないよう、サービス停止を伴うメンテナンス作業は実施せずに進めていきました。
本エントリーでは概要を説明するにとどまりますが、各ステップで試行錯誤したポイントについては次回以降のエントリーで記載していこうと考えています。

  1. AWSとGCPをVPNで接続する
  2. GCPでAWSと同じようにリソースを立てれるようにする
  3. GCPでリソースを一部稼働させパフォーマンスを計測する
  4. 計測したパフォーマンスを元にマルチクラウドを意識した構成/コードに修正する
  5. 修正完了後、GCPの割合を徐々に増やしていく
  6. 運用を整える

*3,4,5のステップは一度ではなく何度も繰り返し、構成/コードを洗練させていきました。

まとめ

良かった点

可用性の向上

前述したようにGCPでLoadBalancerがリクエストをサーバにフォワード出来ず、502のreponseを返すという障害が発生したのですが、AWS/GCPのマルチクラウドインフラを作った後だったため、AWSに寄せて稼働させることができ、その影響を抑えることができました。

パフォーマンスの向上

Cloud Bigtableなど適材適所にサービスを導入し、GCPとAWSで双方で問題なく動かせるよう構成/コードを見直した結果、マルチクラウドインフラ構築前に比べ、パフォーマンスが格段に向上しました。
またAWS/GCPそれぞれのサービスを導入しやすくなり、マルチクラウドインフラ構築後においても、日々パフォーマンスは改善しています。

コストが 約40%低減

データ転送コストを抑えつつ、パフォーマンスを向上させた結果、コストが約40%低減しました。

エンジニアとしてのレベルアップ

まとまった情報があまりない取り組みだったので、自分で考え抜く力、もがいて結果を出すという力が向上しました。

意識しておかなければいけない点

利用サービスが増えることによって、学習コストも増える

プレイドでは「新しいサービス/技術はどんどん触って、いいものはどんどん導入しようという」絶対的な文化があるので本項目は基本的には歓迎なのですが、企業文化やステージによっては考える必要があると思います。

移行コストについて

やってみないと分からない部分はありますが、移行に伴う以下のコストをある程度見積もっておくことは重要です。

  • インフラのコスト：検証時、移行作業時にリソースを追加で立てる必要があるので
  • 人のコスト：インフラの改修だけではなく、サービスのアーキテクチャを把握した上でコードの改修等の作業も必要になってくると思うので、それなりに覚悟は必要になります。折れない心が大切でした。プレイドではインフラ、アプリケーション、opsまで一通り修正をエンジニア2.5人×3ヶ月で実施しました

最後に

私達のマルチクラウドインフラはまだ始まったばかりで、随時、拡張/改善していきたいと思っています。
プレイドでは、マルチクラウドインフラをもっと成長させたい、KARTEを使ってこんなアプリケーションが作りたい！ KARTE自体の開発に興味がある！というエンジニア（インターンも！）を募集しています。
詳しくは弊社採用ページ
またはWantedly
をご覧ください。 もしくはお気軽に、下記の「話を聞きに行きたい」ボタンを押してください！