GCEとGKEのアーキテクチャを一挙公開――GCP活用のコツをgrasys 長谷川祐介氏が伝授

少人数でGCPを運用するgrasys　どんなツールを使い分けているのか？

　grasys 代表取締役社長 長谷川祐介氏はYahoo Japan、大手ゲーム企業、gloopsなどインフラやゲームの世界で経験を積み、2014年にgrasysを設立した。社名はスペイン語で「ありがとう」を表す「gracias」と「system」を掛け合わせたもの。「これまでの経験やお客様、仲間に感謝を込めた」と長谷川氏は言う。

　「grasysはGoogle Cloudのプレミアサービスパートナーですが、GCPのヘビーユーザーと言ったほうがぴったりくる」と笑う長谷川氏。同社はクラウドインテグレーターとして大規模なゲームパブリッシャーやファッションメディアなどのインフラやデータ分析を手がけている。顧客のインフラを手がけているところからMSP（Managed Service Provider）と認識されがちだが、一般的なMSPのように明確に役割分担せず、顧客の環境に深く関わる。顧客インフラのアーキテクチャ設計や負荷計測を一緒に行い、障害復旧も協力するなど、「（インフラを支えて顧客の）プロダクト開発に参加することが我々の存在意義だと考えています」と話す。  

　grasysは創業5年目、社員はまだ17名。うちエンジニアは12名。それでいてVMインスタンスは4500以上となるほど、かなりの規模を運用している。運用には自社開発したツールのほか、オープンソースやパートナー企業のツールを組み合わせているという。自社開発製品にはオーケストレーション「gorc」、監視用プログラム「gmonitor」、監視通知「galert」、ドキュメントの転送を自動化する「gdoc」がある。

　オープンソースでは「Prometheus（コンテナモニタリング）」、「influxdb（時系列データベース）」、「Grafana（可視化ツール）」、「Vuls（脆弱性スキャナ）」、パートナーのツールには、HashiCorpの「Terraform」、「Consul」、「Vault」、elasticだと「elasticsearch」、「kibana」、「beats」、「logstash」などがある。 　 　

　長谷川氏はシステムの特性や要件に合わせて監視すること、規模に影響を受けないオペレーションに力を入れており、傾向監視や状況把握にメトリクスやログのデータが重要となるためデータ収集には力を入れているという。 　

　実際の監視環境におけるアーキテクチャは下図のようになる。オンプレミスやGoogle Compute Engine(以下、GCE) クラスタではgrasysのgmonitor、Kubernetes側（GKE）はPrometheusで監視している。運用効率を高めるにはGCEとGKEを同じ画面に統合することが重要と考え、データをGrafanaで統合している。アラートはいったんgalertで受けてから、要件に合わせてslackやChatworkなどに通知するようにしている。

　GCPのエキスパートである長谷川氏はよく「GCEとGKEをどう使い分けているか」と質問されるという。確かに気になるところだ。

　長谷川氏はこのように回答する。「GCEは基本的にVMなので自由度が高い。そのためリアルタイムでパラメーター変更が容易だ。通信要件が厳しい（負荷が高い）、接続時間が長いものなど（に向いている）。一方、GKEはフロントエンドがHTTP系、シンプルかつ薄いTier構成、ネットワーク的に疎結合の時に選ぶことが多い。ある程度の規模感が維持できる状況であることも選定上は重要で、その上でポータビリティが必要な状況においては良い成果が出やすい。すぐに運用開始できるのがいいところではあるが、事前の設計を入念に行うべき」。

実際の事例からGCP設計のコツを解説

grasys Site Architecture

　まずはgrasysのコーポレートサイトとブログサイト。とてもシンプルで、驚くことにサーバーが1台もない。バックエンドにGoogle Cloud Storage、フロントエンドにCloud Load Balancingを置き、Cloud CDNを使う。これだけで大規模な配信が可能で、応用すれば大量データを配布するスマホゲームアプリにも使えるという。長谷川氏は「とてもシンプルだが、データ配信で強靱な構成にするには鉄板」と強調する。

　ポイントはGoogle Cloud Storageの制限回避。Google Cloud Storageはアクセス数が多いと、レートリミットがかかりアクセスできなくなることがある。そのためフロントで緩衝となるCloud CDNを置くのがいいという。

Mastodon

　もともとMastodonはシングルホスト向きのアーキテクチャだが、長谷川氏が書籍執筆をきっかけに大規模向けの構成を組んでみたのがこちら。

　データ分析だと、データソースはあらゆるところから流れ込むことになる。この構成では多様なデータを受けとめ、効率的にBigQueryに流し込むことを可能とする。なおBigQueryはリアルタイムでデータのインサートが可能だが、grasysではあまりリアルタイムにはこだわらずバルクインサートにすることが多いという。

grasys Data Analysis Architecture

　さらにデータ分析基盤として磨きあげたのがこちら。grasysの標準的なデータ分析基盤のアーキテクチャとなる。BigQueryを大規模に活用する際、安定して運用できる構成になっている。

JobQueue Executor

　こちらは大規模な演算処理のための構成。AWSからのデータをGCPで受けとめ、ジョブキューに渡す。必要な計算数に応じてVMを立ち上げ、不要になればVMを捨てている。要件が特殊だったため、自前で構成したものも含まれるものの、別クラウドサービスからのデータを取り込んで処理する例となる。

GKE Cloud Spanner Architecture

　GKEとCloud Spannerの活用例がこちら。最近増えているという。汎用的な部分だけ抜き出すとこのようなシンプルな形になるが、実際には何パターンかに分かれる。

　grasysではGKEをHTTP系のトランザクション処理だけではなく、常時接続のリアルタイムやストリーム処理にも応用し始めている。また最近ではGKEにおいて複数の処理系を担い、連続処理するような構成も出てきた。elasticsearchのような複数のノードタイプが存在するような構成でも応用できる。

　長谷川氏はポイントをこう話す。「Spannerは大規模な要件にマッチするすごいサービスです。グローバルでけっこうな規模のトランザクション処理があり、それを守りたいといったときに、たくさんのRDBMSクラスタを自前で組まなければいけない運用負荷を考慮すると、大きな効果が出ると感じています。また大規模なバックエンドを安定的に維持することが可能です」。

WordPress Standard Architecture

　WordPressを使う標準的なアーキテクチャ。実際、世界的に有名なファッションのWebメディアで使われている。フロントにCDNを設置することであまり並列することもなく、書き込み系だけ別に切り出すことで少ない台数に収めることができている。CDNは要件に応じて選定するためGoogle Cloud CDN以外を使うことがあるものの、基本的にはこの構成で時間当たり100～1000万アクセスをさばくことが可能だという。

＊＊＊ 　

　　あらためて長谷川氏はGCPへの愛着をこめてこう話した。「処理系はさておき、クラウドサービスの一番はオブジェクトストレージ。GCPのオブジェクトストレージとなるCloud StorageはBigQueryと親和性が高く、レガシーでできないことを可能にしてくれます。個人的にもCloud StorageとBigQueryを組み合わせ、DataPortalで可視化するのが好きでじゃんじゃん使っています。少し勉強すればできるようになるので、エンジニアでない方にもおすすめです。DataPortalはまだ歯がゆいところもありますが、最近ビッグデータ分析企業のルッカーを買収したので今後よくなると期待できます」 

　なお、長谷川氏が登壇した同セミナーにおいて、Google Cloud パートナーエンジニア浦底博幸氏より、「Google Cloud Platformの概要と最新情報」と題して、GCP概要から最近発表になったAnthos（旧Cloud Services Platform）の詳細について解説があった。Anthosは「Hybrid Done Right」という理念のもとに設計されたもので、オンプレとの組み合わせやマルチクラウドなどハイブリッドな環境でKubernetesクラスタを統合的に管理できるようになることが期待されている。