DSOC Infrastructure Group の大澤です。お盆期間は電車が空いていて通勤が楽なので、お盆期間中に働いてそれ以外で休むのが好きです。
さて、先月末に開催された Google Cloud Next Tokyo 2019 に1日だけ *1 ですが参加してきたので、聴講したセッションについてのレポートをお届けします。
会場について
東京プリンスホテルとザ・プリンス パークタワー東京の二ヶ所で開催されました。基調講演はどちらの会場でも見れますが、パークタワーが本会場となっており、東京プリンスホテルは映像が中継されるサテライト会場でした。会場間の移動は増上寺を跨いでの徒歩かシャトルバスです。
見切れていますが、増上寺の横に東京タワーがそびえ立っています。
会場には CTO の藤倉のパネルがありました。２箇所設置されており、Sansanファンである本ブログ読者なら簡単に見つけられたかもしれませんね。
twitter.com#GoogleNext19 の会場にCTO藤倉のパネルが掲出されています。イベントへのご協力の機会をいただきありがとうございます。 #33Tech pic.twitter.com/ejkTbVaAm9
— 【公式】Sansan (@SansanJapan) July 31, 2019
基調講演
ハイブリッド・クラウド、マルチクラウドの先駆けとして促進していくのが Google Cloud の戦略であり、ソリューションの一つとしてリリースされたのが Anthos です。Anthos は今年４月に発表されたばかりで導入事例はあまり多くありませんが、NTTコミュニケーションズのセッションで Anthos と GKE On-Prem の導入セッションがありました（詳細は後述します）。 Cloud SQL for SQL Server、Managed Active Directory がまもなく東京リージョン提供開始というワクワクするリリースがありました。Elastic Cloud が GCP 東京リージョン提供も嬉しいアナウンスです。
Anthos / GKE On-Prem で実現するハイブリッドクラウド アーキテクチャ
Anthos は今年4月のサンフランシスコで発表されたばかりの新しいサービスですが、NTTコミュニケーションズがアーリーアダプタとして Anthos と GKE On-Prem を導入しています。セッションは前半は Anthos、GKE On-Prem の概要、後半は導入事例の紹介という流れでした。
セッション後、登壇した桑山さんと話をさせていただく機会がありました。従来のウォーターフォールでモノリシックな開発体制だったのですが、他チームの機能が実装できないと先に開発ができなかったりと調整が多く必要となっていたことから、リリースサイクルを早めるためにマイクロサービスアーキテクチャを採用したとのことです。
マイクロサービスアーキテクチャを推し進めるために Kubernetes を採用し、元々社内で GCP を利用していたのもありますが、マネージドサービスで実績のある GKE を採用されたそうです。
Anthos やマイクロサービスアーキテクチャを採用した理由や流れがスムーズで納得感が強く、とても聞きやすいセッションでした。
Anthos の特徴
- 既存環境のモダナイゼーション
- ハイブリッド・マルチクラウド環境間の一貫性担保
Anthos Control plane
- クラスタ管理
- サービス管理
- サービスディスカバリ
- トラフィックルーティング
- 認証
- ポリシー管理
GKE On-Prem
- データセンターの VMware 環境
- 最新の Kubernetes にアップグレード
- GCPサービスとの連携
- Audit Logging etc
Anthos Config Management
- ポリシー管理
- セキュリティポリシーをオンプレ、クラウド間で同期
- セキュリティ/監査をコードで管理できる
なぜ GKE を採用したのか
- 関連システムから設備にサーバを要望
- マーケットのフィードバックから企画&開発、メンテナンスというライフサイクルがあり、高速化したい
- Enterprise Cloud
- コンポーネント単位で開発 => マイクロサービス化
- 契約管理、認証機能、課金などは共通機能でそれ以外はコンポーネント別で開発
- 毎月新サービスをリリースできている
Cloud Run アンチパターン
Cloud Run で Metabase を動かしてみてハマったところ何に失敗したのかをわかりやすく解説されていました。 20分のショートセッションですが内容は充実していました。
Cloud Run とは
- ステートレスなコンテナを負荷に応じて自動増減できる環境を Google が管理してくれるサービス
- CPU 1 vCPU
- メモリ最大2GB
試したこと
- Metabase を Cloud Runで構築してみた
- DB は Cloud SQL PostgreSQL
- Cloud Run ではUnixソケット経由で接続
- Metabase の設定は RDB に保存
- 起動するときに DB チェック、セットアップされていないと設定される
起きたこと
- 起動できない
- シェルなどを使って、PORT 環境変数から対象アプリケーションのポートを設定する必要がある
- 公開されているイメージがそのまま使えるとは限らない
- 起動できても止まる？
- Cloud Run ではコンテナ終了ログがない
- ログ上ではコンテナの状態が確認できない
- リクエストが来ないとコンテナが止まる
- 起動に時間がかかるアプリでは起動前にコンテナが止まることがある
- コンテナが起動・停止を繰り返す
- リクエスト待ち&初期処理の高負荷->オートスケール->コンテナが増える->繰り返し
- JDBC は TCP/IP コネクションのみ
- Cloud Run から Cloud SQL につなぐ場合は、パブリックIP か Unix ソケットのみ
- Cloud Run ではコンテナ終了ログがない
まとめ
- 気軽にコンテナを起動できるが、オートスケールや DB との相性は事前に確認が必要
メルペイのマイクロ サービスを支える GKE と Cloud Spanner
メルペイにおける GKE を中心としたマイクロサービスを構築するためのアーキテクチャや、Spanner を採用した理由および運用面でハマったところなど惜しみなく解説してくれた良いセッションでした。
複数サービスの開発を同時並行かつスピーディに行うためにマイクロサービスアーキテクチャを導入していますが、監視をするサービスも増えるため運用面で辛くなります。SLOを設定し、サービスが正常な状態を各サービスで定義することで、本質的な問題に注力できると思います。
Why Microservices?
- メルペイの複数サービスを短期間で立ち上げるため
- 組織を拡大しながら、複数の機能を同時並行で開発する必要がある
- 機能に集中した開発ができる
- その他メリット
- 独立したリソース管理、ストレージも独立
- 障害の局所化 => 可用性の向上
マイクロサービス アーキテクチャ
- GKE クラスタは共通
- すべてのマイクロサービスが同じクラスタに乗っている
- クラスタ自体はプラットフォームチームが構築・運用している
- Namespace 内を各マイクロサービスのチームが開発・運用している
- マイクロサービス単位の GCP プロジェクト
- 各プロジェクトに Spanner や Pub/Sub などを作成している
- Terraform で管理
レイヤーアーキテクチャ
- Client -> API Gateway -> API Service -> Backend Service
- API Gateway
- 共通処理（認証など）とルーティング
- Go言語 で書かれたマイクロサービス
- API Service
- クライアントからのリクエストとレスポンスに対する責任をもつ
- マイクロサービス間の通信のバランシング
- マイクロサービス間は gRPC で通信
- ポート間でコネクションを貼り続けてしまってロードバランシングできない
- Headless Serviceを利用して、クライアントサイドのロードバランシングを行っている
- Backend Service
- 機能のロジック
GKE の利用
- Podの入れ替え
- アプリケーションを Graceful Shutdown 対応を組み込む
- 受け付けているリクエストを処理してから死ぬようにする
- ローリングアップデートの設定をして、なめらかにリリースできるようにしている
- 一部のマイクロサービスでは Spinnaker のカナリアリリースを使っている
- アプリケーションを Graceful Shutdown 対応を組み込む
- 負荷に応じたスケールアウト
- Horizontal Pod Autoscaler
- CPU 使用率を元に Pod 数を調整
- Horizontal Pod Autoscaler
- 権限管理
- Namespace / RoleBinding
- 開発・運用者が担当する Namespace を設定
- バッチ処理
- Job / CronJob
- 不整合発生のチェックや修正などのバッチ処理を行っている
- Microservices platform
- 各チームをオーナーシップを持って、マイクロサービスを構築・運用する
- マイクロサービスで開発するための仕組みを作っている
- 共通のフローでデプロイできるようにするなど
Cloud Spanner の利用
- SQL ライクなクエリとトランザクション、高可用性を実現するフルマネージドなデータストア
- ノードを追加すると性能がスケールする
- 負荷が下がったらノードを減らすこともできる
選定理由
- Cloud SQL
- メンテナンスウインドウのダウンタイム、書き込み性能が目標に達しなかったことから見送り
- MySQL on GCE
- Local SSD を使えば性能がでるが、マイクロサービスが増えていく中で運用面で不安
- Cloud Spanner
- スケール、性能面で問題が無いが、開発経験が社内・社外にあまりなかった
Cloud Spanner における設計
- Primary Keyが重要
- Hotspotを作らない（データに偏りを作らない）
- シーケンシャルなKeyは使わない
- Spannerの気持ちになる
- 公式ドキュメントをちゃんと読む
- どのぐらいの頻度・件数のRead/Writeがあるのか
- データの傾向やクエリの計画を定める
- 開発環境がない
- エミュレータがない、高い
- Spanner の共有インスタンスをたてて、複数チームで共有
- ローカル開発用、CI 用
- Go ライブラリで CI による DB 作成・削除などをしている
- 決済トランザクションは難しい
- どこかの処理が失敗すると、整合性を保つ必要がる
- リトライ、リコンサイル
- メルカリの Tech ブログを参照
Cloud Spanner の運用
- 期待通りのパフォーマンスが出ているか
- エラー率、レイテンシ
- ノードが足りているか
- Query Stats
- ノード数を決めるための指標
- CPU使用率
- High-priority
- 24-hour smoothed (24時間平均）
- 時々、CPU使用率がスパイクするときがあるが、High-priorityはそうでもない場合がある
- CPU使用率
- Spanner 周りライブラリは Go言語 で開発している
- 公式ライブラリにパッチを送っている
Windows ワークロードを Google Cloud に移行する方法
現在進行系で Windows Server の移行をしているので、GCP におけるセッションに参加しました。Windows サーバの移行に関する話というよりも、GCP における Windows の今までの歩みと今後の計画についてがメインでした。時折、デモを交えてわかりやすく解説してくれました。 GKE の Windows Container 対応や、マネージド Active Directory、OS Patch Manager など今後のリリースに要注目です。
今までの Windows 対応
- 2015年 Windows Server 2008, 2012 R2のイメージ
- それ以降もWidows 2016, 2019 や SQL Serverなど
なぜGCPでWindowsなのか
- Googleグレードのインフラストラクチャ
- 信頼性
- ネットワークのレイテンシ
- カスタムVM
- ライブマイグレーション
- コスト削減
- コア単位のライセンス
- モダナイズ
- Kubernetes, GKE
- OSS 特定のベンダーにロックインされる心配が少ない
Windows Server の運用
- Google エンジニアが検証・テストしてライセンス設定したイメージを利用できる
- 用途にあったイメージがない場合は、Marketplaceから探す
- サードパーティのライセンス費用もビルトインされている
- Shielded VM
- ルートキットやブートキットによる攻撃を防御するVM
- コンプライアンスレポート （新サービス、もうすぐ発表）
- Windows、Linux、詳細レポート、コンプライアンス
- OS Patch Manager クラウドとOS全体にわたるパッチアクション （新サービス、もうすぐ発表）
- 既存システムとの互換性がある
- Puppet、Chef
- 既存システムとの互換性がある
- マネージド AD（近日β版）
- オンプレミス AD ドメインとマネージドサービスの接続
- VPC ネットワーク内に AD ドメインが作成される
- 作成完了までに30分程度かかる
モダナイズ
- コンテナのサポート
- .NET クライアントライブラリ
- Visual Studio の統合
- Stackdriver との連携
- GKE for Windows Server Container （現在α版。近日公開予定）
- GKE で Linux と Windows のポッドが混在して管理できる
まとめ
サンフランシスコ と同様に、今回の東京のイベントでもハイブリッドクラウド・マルチクラウド戦略が強く押し出されていました。クラウド移行において、移行してからモダナイズではなく、オンプレに置いたままモダナイズできるようなクラウドジャーニーが用意されており、今後もその方向性はますます強くなっていくと思います。
*1:業務都合がつかずフル参加は見送りました
