AWSのディープな活用事例を学べた2019年1月10日のX-Tech JAWS。2番手として登壇したのはプレイドでSREチームに所属している徳永貴大さん。レスポンスと高可用性を実現すべく、マルチクラウドを活用しているという先進的な事例だった。
![]() |
---|
プレイド エグゼクティブエンジニア 徳永貴大さん |
レスポンスと高可用性が要求されるKARTEのシステム
プレイドがサービスとして提供する「KARTE(カルテ)」はCustomer Experience Platformを謳うWeb上での顧客体験向上サービス。ECを中心とするWebサービス事業者は、KARTEを使うことで、どんなユーザーが、どんな商品をどれくらい見ているかをリアルタイムに可視化でき、付与されたタグに応じてKARTEがクーポンやボタンなど最適なレスポンスを返すことができる。
![]() |
---|
CX(顧客体験)プラットフォームのKARTE |
登壇した徳永貴大さんは楽天でアプリケーションやミドルウェアの開発を担当した後、インフラに強いプレイドにジョインし、3人目のSREとしてシステムの安定運用に貢献しているという。徳永さんはKARTEの技術背景について「インターネットってHTTPというステートレスなプロトコルで実現されているが、そこにステートフルなレイヤーを作っていきたい」と説明する。エンジニアにとっては、確かにこっちの方がわかりやすい。
KARTEで驚くべきなのは、そのリアルタイム性であろう。「ユーザーごとのイベントを1秒あたり最大4万5000くらい解析しているので、1日で13億イベントくらい。しかもリアルタイム性が要求されるので、それらをほとんど1秒以下で戻しています」(徳永さん)というもの。もちろん、クライアントのシステムの一部として機能するので、落ちることは許されず、レイテンシや処理能力の要件もシビアだ。
こうしたパフォーマンスにシビアで高可用性が求められるシステムを実現すべく、プレイドはAWSとGCPを組み合わせたマルチクラウドを採用している。では、なぜマルチクラウドか? 実はKARTEはサービス開始当初、AWSのみで構成されていたという。行動ログの収集と解析処理にEC2を用い、キューイングやキャッシュにElasticCache、データの格納にDynamoDBで構成されていたが、パフォーマンスやスケーラビリティに限界があった。そのため、キューイングをRedis専門のSaaSに切り替え、解析データの保存をBigTableに変えてみたという。
しかし、EC2からBigTableという事業者をまたいだデータの書き込みは通信コストがかかるという問題があった。そこで、GCP側にも同じようなシステムを同一ゾーンに作っていった結果、同じシステムがAWSとGCPの両方で実現されたというわけだ。現在はAWSのDNSサービスであるRoute53でトラフィックを振り分け、AWSとGCPのマルチクラウドでさばいているという。「AWSだけ、GCPだけといってこだわっていると、ベンダーロックインになってしまうので、われわれはユースケースにあった柔軟なシステムを構築できるということで、勇気を持ってマルチクラウドに移行しました」(徳永さん)。
![]() |
---|
KARTEのレスポンスと高可用性を支えるマルチクラウド構成 |
パブリッククラウドの障害でも迅速に復旧できた
マルチクラウド構成は、耐障害性が高い。2018年の7月、GCPのロードバランサーが約1時間ダウンし、Sportfy、Discord、Pokemon Goなど多くのサービスでアクセス障害が発生した。徳永さんは「早朝にPagerDutyでアラートが上がったので、調べてみたら、インスタンスのCPUが全然使われておらず、リクエストがそもそも来てませんでした。ロードバランサーにエラーが発生したのが数分でわかりました」と当時を振り返る。
常時マルチクラウドで運用していたプレイドでは、Slackからトラフィックを変更できるようにしてあったので、一時的にGCPの利用を止め、全トラフィックをAWS側に流すようにした。「データベースはGCP側にあるので、前述したとおり、お金はかかるのですが、サービスが稼働する方が大事だった」と徳永さんは語る。GCPユーザーの大手サービスがアクセス障害に陥ったにも関わらず、SREチームは10分程度で復旧にこぎつけた。「これは自慢でもあるし、マルチクラウドの大きなメリットだと思います」(徳永さん)。
![]() |
---|
GCPの障害時には、トラフィックをすべてAWSに |
今回はGCPの例だったが、もちろん他のパブリッククラウドでも障害は必ず起こる。2017年3月にAmazon S3が3時間ダウンした障害は記憶に新しいし、GCPは2016年にもロードバランサーの障害で2時間サービスがダウンしているという。「人手が介在する限り、障害が起こるのは仕方ない。でも、われわれはマルチクラウドでこれらの障害の影響を回避しています」と徳永さんはアピールする。
AWSとGCPのメリットをうまく使い分ける
サービスラインナップが横並びになってきたパブリッククラウドにおいては、同じシステムを別のクラウドで構成できる。Amazon S3だったらGCPのGCS、AWSのCloudFrontだったらGCPのCloud CDNが使えるはず。とはいえ、構築や運用の手間がかかるのは事実なので、一番コアの解析の部分のみマルチクラウドを使い、管理画面はAWSのみ採用している。
![]() |
---|
プレイドはリアルタイム解析に関わる部分は両方で動かせるようにしている |
その後、徳永さんはAWSとGCPの比較を披露。AWSに関しては、「AWSはいい意味で枯れているし、安定している。だいたいのサービスはAWSで作れると思うし、実際世の中の多くのサービスはAWSを使っているはず」とコメント。一方でGCPに関しては、「BigTableやBigQuery、ML系などグーグルのとがった技術を使えます。たとえば、弊社のBigTableはデータ容量が現在260TBくらいになっているけど、全然パフォーマンスが劣化しません。これってすごいこと」とアピールする。基本はAWS、尖った分野はGCPというのが、徳永さんのマルチクラウド論だ。
まとめに入った徳永さんは、「マルチクラウドで柔軟なシステムを構築できます。ただし、事業者間の通信はお金もかかるし、VPNが詰まることもあるので、注意してシステムを作ってください。可用性の高いサービスを作りたい場合はオススメ」とアピール。お約束の人材募集を行ない、会場との質問タイムとなった。


この連載の記事
- 第14回 スマートニュース、動画チャンネルでのMLサービス活用を語る
- 第13回 AIで契約書のトラブルを未然に防ぐ「AI-CON」を支える開発・運用体制
- 第12回 フジテックの情シスが語る「3度目の正直」になったIoTプロジェクト
- 第11回 岡山県玉野市のデマンド交通を支えるAWS+SORACOM
- 第10回 身体もWebサイトも健康一番!ヘルスケアとプライバシーのX-Tech
- 第9回 AI英会話アプリ「TerraTalk」のHeroku+AWS活用法
- 第8回 太陽光発電の監視システムをサーバーレスで実現した話
- 第7回 指タップで魚市場の鮮魚が買える「UOICHI」が面白すぎた
- 第6回 「ママリ」を支えるコンテナはチームみんなで育ててきた
- 第5回 マルチテナンシーの難しい課題をAWSで解決したSmartHR
- この連載の一覧へ