GCP PCDの資格に関係するHipLocal社のケーススタディについて、
30分でまとめた。30分しか考えてない。
本当は他のブログのようにもっと細かく要件に対する全容がかけたら良かったなあと思ったり。
本当に、個人的なメモ書きなので、ブログに書いて公開してもよいものなのかなあと思ったりした。
正直なところ、スマフォから参照できる用の公開。
表題の通り
GCP PCDの資格試験に登場するケーススタディ「HipLocal社」
詳しくは以下URLを見てください。
https://cloud.google.com/certification/guides/cloud-developer/hip-local-case-study?hl=ja
2022/03/28現在、上記URLに記載の内容を以下に引用し、個人的なメモ書きを追加していく。
概要の概要
まず、大雑把にそれぞれのお話を確認する。
会社概要
HipLocal は、ご近所とのコミュニケーション促進を目的としたコミュニティ アプリで、催し物やスポーツイベントの企画段階において広く利用されています。また、地域コミュニティとのつながりを育むために企業が利用している例もあります。HipLocal はダラスの一部の地域で提供が開始されたばかりですが、世界中に急速に広がり始めています。HipLocal のユニークな超地域コミュニティ密着型 コミュニケーションおよびビジネス活動は、今世界中で求められています。
つまり
mixiのような、SNSを運営しつつ、イベントも開催するような会社。
地域密着で、ビジネス上にも利用されている。
上層部の声明
HipLocal はナンバーワンの地域コミュニティ アプリです。このサービスを世界に展開する機は熟しています。当社のベンチャー キャピタル投資家は、このビジネスの急成長を期待するとともに、オンラインで結びついた新たな地域コミュニティや仮想コミュニティのメンバーに、互いにどれだけ離れていても同じようなすばらしいエクスペリエンスが提供されることを望んでいます。
つまり
地域密着SNSを全世界へ展開したい。ってお上は考えてるってわけ。
特に費用を少なくしろ、この地域特化しろ、みたいなことは名文されていなかった。
ソリューションのコンセプト
HipLocal は、既存のサービスに最新の機能を追加しながら新しい地域に進出し、世界中のユーザーにより良いサービスを提供したいと考えています。また、こうした地域を現地のタイムゾーンでサポートするために、新たにチームを採用してトレーニングすることを計画しています。この新チームは、アプリケーションがスムーズにスケーリングできていることを確認し、アプリケーションの明確な稼働時間データも提示し、問題が発生した場合には その分析と対応も行います。
つまり
機能を追加しながら、新しいエリアに拡大して、世界中へ展開したい。
世界中での展開のためにタイムゾーンのような現地の状況に合わせて、インフラ対応が必要になっている。
既存の技術的環境
HipLocal の環境には、オンプレミス ハードウェアと Google Cloud で実行されているインフラストラクチャが混在しています。HipLocal チームは、自社のアプリケーションはよく理解していますが、世界規模のアプリケーションの経験はわずかです。HipLocal チームの現在の技術環境は次のとおりです。
・既存の API は、Google Cloud でホストされている Compute Engine 仮想マシン インスタンスで実行されています。
・ステータスは、Google Cloud 内の単一インスタンスの MySQL データベースに保存されます。
・リリース サイクルには、QA テスト実行のための開発停止期間が含まれています。
・このアプリケーションには一貫したロギング機能はありません。
・アプリケーションのデプロイは、平日夜のトラフィックの少ない時間帯にインフラストラクチャ エンジニアが手動で行っています。
・稼働時間を示す基本インジケーターがあり、API が応答しない場合は頻繁にアラートが発行されます。
つまり
オンプレ環境とクラウド環境が混じっている。
そして、世界規模でのサービス展開の経験がない。
特に以下の問題がある
・従来通りのVM上で構成されたインフラ環境
・開発サイクルにおける検証フェーズにタイムロスが存在
・ログの一貫性も少ない
・デプロイは現地夜中に手動で行っている。
・死活監視で頻繁にアラートが上がっている。
ビジネス要件
HipLocal の投資家は、対象地域を広げて現在おかれている需要の高まりに応えたいと考えています。投資家からの要件は次のとおりです。
・アプリケーションが利用できる地域を拡大する。
・サポートできる同時ユーザー数を 10 倍に増やす。
・ユーザーが別の地域を訪れた場合にも、一貫性のあるエクスペリエンスを提供する。
・ユーザー アクティビティの指標を取得して、サービスを収益化する方法を把握する。
・新しい地域の規則（GDPR など）に準拠する。
・インフラストラクチャの管理にかかる時間とコストを削減する。
・クラウド コンピューティングに関する Google の推奨方法を採用する。
・・アプリケーション ライフサイクル管理のワークフローとプロセスを標準化する。
・・サービスレベル指標（SLI）とサービスレベル目標（SLO）を定義する。
つまり
マルチリージョン環境
インフラ規模を増大
ユーザ情報を利用した分析要件
GDPR対応など対応（エクスポートなど、データ移行がスムーズにできること）
ライフサイクルや管理などのプロセスを標準化し、SLIやSLOを定義、達成するようにGoogleのベストプラクティスに従う
技術的要件
・オンプレミスのデータセンターとクラウドホスト型のアプリケーションおよびインフラストラクチャとの間で安全な通信を提供する。
・アプリケーションで使用状況の指標とモニタリングを提供する。
・API に認証と認可を用いる。
・新機能をより迅速かつ正確に検証できるようにする。
・ロギングとパフォーマンス指標で実用的な情報を提供して、デバッグ情報やアラートを提供できるようにする。
・ユーザーの需要に応じてスケーリングできるようにする。
つまり
オンプレとクラウド環境を安全な通信でやりとりする。
アプリケーション毎でモニターする。
APIに認証を実装する IAM
新機能を早くかつ適切に
ロギングやパフォーマンスからデバッグやアラートなどを利用する。
スケーリングできるようにする。
全体を通して
どんな言語で作られたアプリケーションかは定義されていない。
GCEレベルでの従来な構造でもよく、Cloud RunやGKEなどのコンテナ運用でもよいし、App EngineやCloud Functionsの場合もありえる。
しかし、問題はマルチリージョン対応させることと、自動的なスケーリングができることが望ましいだろう。
前段はGKE＜Cloud Run＜Cloud Functions＜App Engineの順番で考えたほうが良さそうだ。
また、デプロイ方法は、Cloud BuildやCloud Deployなどを利用して、開発コードを検証環境への自動化を進め、QAテストの手間や、本番環境への手動デプロイの手間が最小化ができる。
Cloud Buildによるテストにおいて、検証環境のためのコンテナ作りや、プライベートプール・サーバレスVPCコネクタも必要かもしれない。
（Cloud DeployはGAしてから日数も少ないため、テストには出なさそう。。。）
CSRとCloud Buildの連携も重要そう。この連携はCloud Build単体でトリガーできる。
CSRによるトリガーでCloud Buildが動作し、Cloud FunctionsやApp Engineにdeployする。
Cloud Build上で検証を動かすということもする場合もあるらしい。
データウェアハウスは現状VM上のMySQLを利用している、そのため移行の手間を少なくする必要があればCloudSQLだが、
水平スケーリングやマルチリージョン対応させるためにCloud Spannerが良さそう。
また、SpannerやCloudSQLでは分析用途やレイテンシに関してに難があることがある。
Memorystoreを利用する場合はマルチリージョンには対応していないので、App Engineなどの構成は注意しないといけない
分析用途ではBigQuery一択だろう。
そういえば、SQL系から脱却して、NoSQLへ移行するという話もありえる。
レイテンシ重視であればBigTableだろうが、この要件的にはFirestoreで良さそうだ。
Firestoreといえば、ある記事とそれに対するユーザのコメントという、よくあるニュースサイトのようなサイト要件がよく見られる。（実際HipLocal社のサービス的にはそれに近いだろう。）
この場合、記事の数や、コメント数など、未知数であることが考えられる。
Firestoreのフィールド値は1MiBが上限であったり、サブコレクションの最大数が100だったりするため、記事のドキュメントに対して配列やサブコレクションでコメントを管理するのではなく、ユーザそれぞれのプロファイルに対してキーを保存して、キーからドキュメントを拾ってコメント内容を拾う。という方法が良いらしい。
といっても、他のPCD過去問題集でそう書いてあっただけで、記事についているコメントを拾ってくるにはどうすればいいんだって思ってる。
そういう場合は、コメントのキーではなくて、多分ユーザのキーを保存するんでしょう。（だからPCD問題としての記事にコメントのキーを保存するのは間違い？）しらんけど
オンプレとクラウド環境の紐付けは、Dedicated Interconnect（→Cloud Interconnectに名前が変わったっぽい？）がすぐに出てくるが、オンプレとGCPを直結して、インターナルな接続を利用したい場合でもかなり限られるかと思われる。
IAPやCloud VPNで事足りると思われる。
また、GCSへあげたりすることで、移行を早めても良い。
クラウド間のデータ転送や、1TBを超えるような場合はStorage Transfer Service (PCAの範囲なので出てこないかと)
APIで認証を実装するような要件がある。サービスアカウントの問題や、IAP、アップロードなどの短期間のOauth認証を考えないと行けなさそう。
APIで実装という話から、Cloud Functionsでバージョニングや、それに伴ったCloud Endpointsの利用もあり得る。
App Engineでトラフィックの分散を行って、A/Bテストやカナリアテストも考えられる。
App Engineでのトラフィックの分散はIP単位やクッキー利用で行う。
ログの一貫性がないという問題はCloudLoggingを利用している限り問題にはならなさそうだが、BigQueryへのSinkも念頭に置いておいたほうが良さそう。
LoggingのデータをPub/SubやGCSにあげて、Dataflowで(一貫性のあるログデータに)処理し、それをBigQueryで分析する。
Loggingから直結はBigQueryならできそうだが、Dataflowなどで処理してからというのは無理そう。
死活監視はCloud Monitoringで可能だし、このあたりはHipLocal社特有の解決方法としては特に問題にはならなさそう。
オンプレ環境からCloud LoggingやMonitoringを利用するには、Google製のfluentdやら、Cloud Logging/Monitoringのエージェントをインストールするだけで使えるというのは気をつけておくぐらい。