この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
最近、結構な頻度で聞くようになってきた「マルチクラウド」という単語。
いろんなクラウドの良いとこ取りができるのでメリットしかなさそうだけれど、運用・保守面含めて、「そんな簡単じゃないやろ〜」と一歩引いた視点で自分はみていました。
恐らく、Developers Summit 2018において、マルチクラウドというテーマで話されていたのは、このセッションだけじゃないでしょうか。
結論から言うとすっごい面白かったです。マルチクラウドで構成組む時に必ず出てきそうな問題点の解説もあり、非常に貴重なノウハウが満載なセッションでした。
__ （祭） ∧ ∧ Y ( ﾟДﾟ) Φ[_ｿ__ｙ_l〉 ﾏﾙﾁｸﾗｳﾄﾞﾀﾞ ﾜｯｼｮｲ |_|＿| し'´Ｊ
講演内容
講演者は、株式会社プレイドの竹村 尚彦さん。
マルチクラウドで構築する大規模解析サービス～戦略とポイントについて
「KARTE」は、サイトへ来訪したお客様の特徴や行動を0.x秒以内に解析して可視化し、個々のお客様にあわせたコミュニケーションを実現するサービスです。 2017年2月末時点で累計解析ユーザー数は12.5億人、年間のEC領域解析売上金額は5000億円、導入社数は1,430社を超えています。
本セッションでは「KARTE」を支えるマルチクラウドインフラの構成とその設計/運用などにおける戦略についてお話する予定です。引用：マルチクラウドで構築する大規模解析サービス～戦略とポイントについて
講演資料
以下本文中の画像は、上記講演資料より引用させていただいております。
ウェブ集客プラットフォーム「KARTE」の紹介
皆さん、KARTEご存知ですか？知っている人、挙手願います！はい！少ないですね〜ｗ
「KARTE（カルテ）」は、ウェブ接客プラットフォームで、ウェブ訪問者へのほぼリアルタイムな接客を可能にします。GoogleAnalyticsのように、ページにJavaScriptのタグを埋め込むことで、導入できます。
もちろん解析だけではなく、訪問者に対して様々なアクションを出し分けることができます。Webサイトへのポップアップ表示とか、３回目の来訪者には「いつもありがとうございます」とメッセージだしたりとか、ユーザー属性によるページの出し分けにも対応してます。
KARTEのサービス規模です。ローンチしてからだいたい3年。数字としては大規模といって良いと思います。特にトラッキングイベント6000event/secに対して、解析時間ミリsecを実現しているのは、かなりがんばってます。
次に代表的な数字を時系列で紹介します。
2年程前からの数字ですが、Event=サービス規模が増大しつつもコスト面効率が年々良くなっています。さらに特筆すべきは運用に携わるエンジニアの数。ここ数年、ほぼ横ばいです。このあたりは、我々としても非常にアピールしたい点です。具体的には、SREは2人です。この2人で、殆どの運用を回しています。
で、この「？」において、重要な方針転換をしています。それが、今回のメインテーマ「シングルクラウドからマルチクラウドへの変更」です。
インフラ構築戦略の変更「シングルクラウドからマルチクラウドへ」
マルチクラウドは一見取り掛かりが難しそうだが、うまくやると様々なメリットがあります。今回は、4つのポイントに絞って、お話します。
最初に全体構成はこちら。とりあえず、フーンとイメージだけ掴んでおいてください。
コンピューターリソースなどについては、IaaS（EC2、Compute Engine）を利用しています。
ポイント1「各プロバイダーのいいとこ取りをする」
クラウドプロバイダと一口にいっても、いろんなプロバイダーが存在します。なんでも揃えている「AWS」や「GCP」。対して、一点特化型のものなど。各プロバイダ/サービスには得意分野があります。
AWSは歴史が長いだけあって、やっぱり安定感があります。GCPはAWSに比べて後発ですが、Bigtable周辺が強かったり全体的にエッジが効いたサービスが多い印象ですね。やっぱり特性が違うなぁと感じます。
これら得意分野をいいとこ取りすることで、よりプロダクトが強くなりました。
一例として、リアルタイム解析におけるいいとこ取りを紹介します。ここでは、負荷コントロールのキューイングにredislabs、解析データ保存にGCPのCloud Bigtableを採用しました。
キューイングに「redis cloud」を採用
皆さん、redis cloudご存知でしょうか？redis enterpriseをクラウドで提供しているサービスです。我々のユースケースではキューイングの要件にばっちりハマっていて、スケーラビリティに優れいていて高パフォーマンス、さらに高可用性で素晴らしいサービスです。
特に課金体系がDBのデータ量に依存しているところが、弊社サービスと相性が良い。弊社ユースケースでは、DBのデータ量はわずかで逆にネットワーク転送量が非常に大きいのですが、redis cloudはそこにかかるコストがゼロ。もしかしたら、redis cloudから見るとあまり良い客とは言えないかもしれません（笑）。
解析データ保存に「Cloud Bigtable」を採用
解析データの保存に現在は、GCPのCloud Bigtableを利用しています。スケーラビリティ、可用性、レイテンシ全般に満足していてい、カタログスペック以上のパフォーマンスががでており非常に満足しています。
これら、シングルクラウド状態からプロダクトの特性に合わせて他のクラウドサービスの導入により、全体としてパフォーマンスや可用性が向上し、ランニングコストや運用コストを削減できました。
ポイント2「プロバイダの障害を別プロバイダでカバーする」
どれだけ素晴らしいサービスでも障害は起こります。これは仕方ない。可用性が高いストレージの代表格であるAWSのS3でさえ、2017年3月に大規模な障害が発生しています。障害の中にはシングルクラウドでは対応しようがないものも存在します。
「KARTE」はお客様のサイトの一部となるので可用性はとても重要なので、マルチクラウドによって耐障害性を高めた事例を紹介します。
GCPのCloud Load Balancingで障害が発生した時は、Route 53のTrafficFlowを利用し、ルーティング比率を切替えることで対応できました。
各プロバイダーはそれぞれの領域において似たようなサービスを提供しているので、マルチクラウドにより代替の適用が可能な場所はそれなりにある。例えば、GCPのGCSやCloudCDNに対応する、AWSのS3やCloudFrontなど。ただ、システムの重要性と実現の難易度、コストを見極めは必ず必要なのでそこは注意しましょう。
ポイント3「プロバイダまたぎの通信に注意する」
プロバイダ間の通信はコスト面でも通信の安定性の面でも、同一プロバイダ内通信に比べてデメリットが大きい。
AWSのEC2からGCPのBigtableに通信させていたときには、頻繁なRead/Writeによりコストが非常に高かったのですが、Bigtableと同じZoneにGCEを構築することで、コストもレイテンシーも両方向上させることができました。
基本的な考え方として、プロバイダ間の通信はインターネットを必ず介すため、同一プロバイダ内の同一ゾーン内など閉じたネットワークに比べて、通信の速度および安定性が必ず低下するので、それを前提で各システムを構成する必要となります。
ポイント4「複数のプロバイダーを統一的なインターフェースで運用」
インフラの構成管理、監視、アプリケーションデプロイなどは自分たちで面倒を見ないといけないが、それらを補助するツールは、各プロバイダ毎に独自のフォーマットで用意されており互換性がありません。そりゃそうですね。構成管理で言えば、GCPにはDeploymentManagerがあり、AWSにはCloudFormationがあります。
そういった場合には、OSS、サードパーティーのサービスをうまく利用する必要があります。その例がこちら。
構成管理にTerraform、アプリケーションデプロイにSpinnaker、DATADOGを利用します。
構成定義ファイルやアプリケーションはGitHubにPRしたのち、werckerをトリガーとして、各OSSをキックする仕様としています。
講演のまとめとお知らせ
今日の講演のまとめです。
サービスの成長とシングルクラウドの限界から「プロバイダにとらわれずマルチクラウドに構成を組む」戦略にシフトした。
- プロバイダのいいとこ取りをする
- プロバイダの障害を別プロバイダでカバーする
- プロバイダまたぎの通信に注意する
- 複数のプロバイダーを統一的なインターフェースで運用する
最後に、今回紹介したマルチクラウドへの取り組みは、codezineなどで記事にもしているので、是非、こちらも合わせてご参考いただければと思います。
大規模解析サービスを支えるGCP活用事例連載一覧：CodeZine（コードジン）
AWSとGCPでマルチクラウドインフラを構築した話とそのポイント| PLAID engineer blog
エンジニアも絶賛募集中です！
濱田感想「どんな組織でも実現できるわけじゃないが、できる組織はマルチクラウドのメリットを十分享受できる」
講演終了後、Ask The Speakerエリアでスピーカーの竹村さんに濱田直撃。
濱田「マルチクラウドって、良いとこどりすればもちろんメリットが出る部分もあるかと思いますが、実際に開発・運用していくにあたっての現場の負荷ってどうでしょう？シングルクラウドの構成でも覚えることや検証しないといけないことは山ほどあると思いますが、それをマルチクラウドであれだけの規模で実運用するのって、メリット以上にむっちゃ大変だと思うんですが？」
竹村さん「うーん、そうですね。一つはパブリッククラウドとしての共通性による学習の容易さはあると思います。AWSをある程度知っていれば、それと照らし合わせてGCPならこれとか、あたりがつけやすいですね。あとは、会社のメンバー、みんな新しいもの好きってところが一番大きいんじゃないでしょうか。」
つえぇ。。。
すっかり忘れていたんですが、プレイドさんのこちらの記事AWSとGCPでマルチクラウドインフラを構築した話とそのポイントに、自分がブコメつけていたのを思い出しました。
個人的には、今でも、マルチクラウドはまだまだ難しいというか、メリット面だけを享受しようとして安易に手を出すものではないという感触を強く持っています。
でも、それが技術的にタフな挑戦だったとしても、新しいことやまだ誰もやってなさそうなことにチャレンジしていく精神がある組織なら、6000events/secをミリ秒単位で捌く規模のサービスも運用できるということを、目の当たりにしました。講演ではあまり話されていなかったですが、本番運用前の事前検証や、サービス運用後の苦労も相当あったかと思います。
技術面でも、有用なポイントが多数ありました。パブリッククラウド間のネットワークや通信の障害性観点の注意点とか、統一プラットフォームに寄せた運用の統一化とか、パブリッククラウド以外の専門プロバイダの導入など、実運用されているならではの視点の話が満載で面白かったです。
平たく言えば、「オープンマインドで使えるものはなんでも使ってしまえ」の精神ですかね。そういった視点が満載の楽しいセッションでした。自分も一エンジニアとして、オープンマインド、忘れないように頑張っていきたいと思います。
それでは、今日はこのへんで。濱田（@hamako9999）でした。
0
