Google Cloud Platformエンタープライズ設計ガイド　vol.5

続きです。

８章　運用監視サービス

Stackdriver：運用監視サービス。マルチクラウド環境で稼働しているアプリケーションやサービスのモニタリング・エラー検知、分析やデバッグが可能。
例：Stackdriver　Monitoring：メトリクス監視、イベント情報収集、ダッシュボード、アラート通知など

Stackdriverはオンプレ時代より利用してきた人でを介した障害対応やオペレーションのトリガーとしての運用監視ツールの単純代替ではない。クラウドネイティブなシステム設計を前提とする自動化されたオペレーションのトリガーとしての運用監視ツールであり、効率的なアプリケーション開発を助けるツールである。クラウドネイティブな設計のもとにStackdriverを利用することで、人手を介していた運用監視業務は効率化・削減され、運用監視業務の考え方・あり方が根本的に変わる。
とはいえ既存の運用監視設計などの考えをそのままにGCP環境に移行することももちろん可能である。
Stackdriverはアプリケーション開発効率化にも貢献する。近年、システム開発ではアジャイル開発をはじめ様々な手法が用いられ、開発サイクルをはやくまわしていくことが求められる。そのためにはエラーやパフォーマンスの低下の原因を分析し、素早くデバッグする必要がある。Stackdriverを用いてError Reportingで多発しているエラーや新しいエラーをダッシュボードに示し、Traceでレイテンシを詳細に分析しボトルネックの発生場所を迅速に突き止めDebuggerで実行中のアプリケーション停止や処理速度を下げずに本番環境でのデバッグ作業を可能にする。

【運用監視業務を行うためのStackdriver】
Monitoring：GCPおよびAWS帖に構築したアプリケーションからメトリクス、イベント、メタデータを収集しダッシュボード上での可視化やアラートの発報などをおこなうモニタリングツール
Logging：Monitoringと同様にGCPおよびAWS環境で利用することが可能なログ収集サービス収集したログデータやイベントを探索・分析・モニタリング・通知を行うことができる。

リソースのグループ化
Compute Engine やEC2のVMインスタンスを個々のリソースとして監視することも可能だが、Webサーバの役割を担っているCompute Engine インスタンスすべて、などの意味のある単位でリソースをグループ化し、１つの塊としてモニタリングすることが可能である。これはサービスを提供し続けることが重要であるという思想を体現している機能であり、オートスケールなどの機能と密接にかかわる。

ダッシュボード機能
自分で指定したメトリクスをグラフィカルに表示するダッシュボード機能がある。複数ページ作成可能であり、複数のチャートをひとつのダッシュボードに表示することも可能。

アラート機能
メトリクスと大賞のリソースに対して、閾値や状態を指定する「条件」項目と、送信先を指定する「通知」項目を設定する。

【コンピューティングサービスの運用監視】
最も多い利用方法はおそらくサーバ監視。
メトリクス監視機能、プロセス監視機能、UptimeChecks機能およびLoggingを利用することでCompute Engine/AppEngine/KubernotEngine/AWS EC2に対する様々な監視を行うことが可能。

９章　GCPを活用したWebシステムの設計・構築

オンプレ→クラウド環境へのECサイト移行をテーマにエンタープライズ企業でよくあるシナリオのケーススタディ。

【シナリオ】
他社のインターネットデータセンターのハウジングスペースに自社で調達したサーバ/ネットワーク機器を設定しECサイトを運営しているが、ECサイトでの取引量拡大に追従することが困難にななってきた。そこでぱぐりっくクラウドへ移行を決意しGCPを検討した。

【移行方法】
Lift&Shift方式で移行。
Lift&Shift方式：従来システムをできる限り変えずにクラウド環境へ移し替える方式。方式を選んだ理由は３つ
①ハードフェアの保守期間終了が３か月に迫っていた
オンプレミス環境の一部ハードウェアのEOSL（End of Service Life)が３か月に迫っており稼働させ続けるには新規ハードウェアの調達が必要となる。EOSLまでにアプリケーションを含めてGCP移行も選択肢にあるがECサイトは売り上げの２０%を占める割合となっておりGCPへの移行は極力リスクを回避する必要があった。

②自社社員および委託業者のスキル不足

自社社員はオンプレミス環境での操作・構築・運用には慣れているがクラウド環境の経験はなかった。また取引しているSIerもGCPに精通しておらず一足飛びにクラウドネイティブに飛び込むのはリスクが高かった

③GCPマイグレーション可能なアーキテクチャ

現行ECサイトは一般的なEwbアーキテクチャでありGCPへの移行に際し大幅なアーキテクチャの見直しが不要であることが事前の調査で判明していた。

【移行後の構成】
基本アーキテクチャは変更せずWeb/APサーバとDBサーバはCompute Engine を採用しWeb/APサーバにはActive-Active構成、DBサーバはActive-Standby構成とした。
（Active-Active：同じ機能を持つシステム要素（機器や通信回線等）を複数用意し、これらを組み合わせて全体のシステムを構成する、冗長化手法の1つ）
（Active-Standby：部のシステム要素だけが稼働し、他のシステム要素は待機状態）
画像などのファイルサイズの大きい静的コンテンツはCloud Storageに配置することで負荷のオフロード化を実現した。
運用監視の仕組みとしてはStackdriverは採用せず、オンプレミス環境にある既存の運用監視基盤から監視する構成とすることで移行設計の時間短縮化を図った。

ネットワーク構成としてはマルチゾーン構成を採用した。
（マルチゾーン構成：主な利点は、データベースの可用性を強化）
（フェイルオーバー：現用系コンピュータサーバ/システム/ネットワークで異常事態が発生したとき、自動的に冗長な待機系コンピュータサーバ/システム/ネットワークに切り換える機能）
オンプレミス環境は単一のDCで稼働しており稼働停止した際はECサイトの停止を余儀なくされる状況となっていたが移行後の構成では単一ゾーンが停止した場合でもECサイトが継続可能な構成である。マルチゾーン構成は設計の難易度が低いため単純意向を行う際も検討を推奨。

検討すべきポイント

【サーバに割り当てるIPアドレスの変更】

既存オンプレミス環境とDCとGCPをOSI7階層のレイヤー２で接続することができないため、サーバのIPアドレスを変えずに移行できない。既存オンプレミス環境にある他システムと完全に疎結合なシステムであれば既存オンプレミス環境とGCPを連携させない構成とすることは可能だがそれはおそらく稀。
GCP上のサーバに割り当てるIPアドレスは変更する前提で連携するシステムの洗い出しと修正箇所の調査が必要となる。

【OSやミドルウェアのバージョンアップ】
オンプレミス環境サーバからブートディスクイメージをCompute Engine にインポートすることでOS,ミドルウェアのバージョンを変えずに移行が可能になる。ただし、サポート期限があるためこのタイミングでOSやミドルウェアのバージョンアップの検討を推奨。

【ソフトウェアライセンスの考慮】
商標ソフトウェアを使用している場合課金単位の確認が必要となる。特に物理プロセッサや物理コア単位で課金するライセンスの場合、GCPへのライセンス持ち込みが困難となる。またGCPへのライセンス持ち込みができてもスケールアップ・スケールアウトの際にライセンス課金単位が制約されることが多い。

GCP移行後のマネージドサービスの活用

運用の課題

【インフラ維持管理負荷】
ECサイトの規模・重要度が増大した現在ではインフラの維持管理活動（ハードウェア障害対応・増強・メンテ・バージョンアップなど）はシステム担当者の大きな負担となっていた。GCP移行によってハードウェアレイヤーの維持管理からは解放されるがOS,ミドルウェアの維持管理は残る。今後の規模拡大を図るためにはシステム担当者の維持管理負荷軽減が必要となる。

【突発的なピーク負荷】
突発的ピークを処理するための余剰リソースをかかえておくことはコスト負担が大きい。よって現行環境では流量制御の設定を行い接続可能なアクセス数を制限していた。ECサイトにとってユーザからのリクエストを受け付けないことは機会損失となるため突発的な負荷に対して自動で処理リソースを増大するアーキテクチャが求められる

新アーキテクチャ

この課題を解決すべくマネージドサービスを活用した。インフラレイヤーの設計・維持管理をクラウド事業者に任せ宇ことによって、インフラ維持管理負荷の大幅な削減が期待できる。

本書の構成ではWeb/APサーバの代替としてフロントエンドにAppEngine、バックエンドにKubernetesEngineを採用した。
AppEngineのデータストアとしてCloud DataStoreを採用することでCloud SQLへの問い合わせ負荷の軽減を図っている。また、プライベートなDocker RegistoryとしてContainer Registoryを採用しKubernetesEngineのコンテナイメージを管理する。
DBサーバの代替としてCloud SQLを採用。
フェイルオーバレプリカを作成することでActive-Standby構成を実現。またリードレプリカを作成し、処理負荷の分散を図っている。
運用監視サーバの代替としてStackdriverを採用。
マネージドサービスに対するきめ細やかな監視が可能となる。

次項にマネージドサービスを利用する際の検討ポイントを列挙。

DBサーバのマネージドサービス化

RDBサービスとしてはCloud SQLとCloud Spannerがある。Cloud Spannerは既存RDBからの移行先として採用するには癖が強く、Cloud SQLと比べ高価なサービスとなるため大規模水平スケーリングを必須としない今回のサービスではCloud SQLがベター。Cloud SQLの注意点は以下。

【Cloud SQLではMicrosoftSQLServerがサポート外】
Cloud SQLのサポートは現時点でMySQLとPostgreSQLのみ。採用する場合にはMicrosoftSQLServerからMySQLまたはPostgreSQLへのマイグレが必要となる。

【オートスケール機能が備わっていない】
構築時にマシンタイプを手動指定するため負荷に応じて自動的にリソースを拡張でするオートスケール機能はない。突発的なアクセスへの対処方法としてリードレプリカによる参照処理の負荷分散や、一部処理をCloud DataStoreで処理するなどの工夫が必要。
特にCloud DataStoreではアプリケーションの負荷に応じてシームレスかつ自動的にスケールするため突発的なピーク負荷が発生するようなケースにおいては積極的に活用したい

Web/APサーバのマネージドサービス化

AppEngineの活用を推奨。
サーバのメンテナンスが不要でかつ負荷に応じて自動でスケールできるためインフラ維持管理負荷の削減、突発的なピーク負荷への対応が可能。
ただ、アプリの制約上、AppEngineのみでの処理の完結は困難なことが多い。そのような場合にはフロントエンドはAppEngine、バックエンドにはKubernetesEngineといった構成も候補となる。KubernetesEngineはコンテナ管理としてデフェクトスタンダードになったKuberneteをベースとしたコンテナ環境である。KubernetesEngineを採用することで自動デプロイ、オートスケーリング、アプリ・コンテナの運用自動化が可能となりインフラ維持管理負荷を削減d寝きる。

管理ツールのマネージドサービス化

OS上にエージェントを導入するのが一般的であるため、導入できないGCPのマネージドサービスを監視するには工夫が必要。Compute Engine やKubernetesEngineといったエージェントを導入するサービスを監視する場合でもオートスケールによるスケールアウト・スケールインを実現する場合その監視方法は課題になりやすい。
Stackdriverを使うのが協力であり、GCPのマネージドサービスの監視も可能となっているため積極的に活用したい。

最後のクラウド環境の構築をvol6として幕を閉じたいと思います。続く。