このページの本文へ

業界を知り、業界をつなぐX-Tech JAWS第15回

AWSとGCPの両刀使いで高い可用性とレスポンスを実現したKARTE

2019年02月07日 07時00分更新

文● 大谷イビサ/TECH.ASCII.jp

  • この記事をはてなブックマークに追加
  • 本文印刷

 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が詰まることもあるので、注意してシステムを作ってください。可用性の高いサービスを作りたい場合はオススメ」とアピール。お約束の人材募集を行ない、会場との質問タイムとなった。

■関連サイト

カテゴリートップへ

この連載の記事