# バッチ処理の改革バッチ処理の改⾰はアプリケーションへの影響が⼤きいため、以下のノウハウを参考のうえ可能であれば検討すること。 ## マネージドサービスの選択 ### ジョブ管理を提供するサービスをどのようなユースケースでどういう選択をするのかジョブ管理にはジョブの実行制御を行うオーケストレーション系サービスと、計算リソースを提供する実行コンピュート系サービスが存在する。なお、タイムアウトなどの制約があるため、各サービスの組み合わせには注意すること。 - オーケストレーション: Workflows、Cloud Composer、Cloud Scheduler - 実行コンピュート: Cloud Functions、Cloud Run、Google Kubernetes Engine(GKE)、Compute Engine、Dataflow ### オーケストレーションサービス検討のポイント 30分以内に完了する処理の場合、オーケストレーションはCloud Schedulerの利用を検討する。ジョブターゲットを選択・連携することで、後述する実行コンピュートを定期的に実行することができる。
ジョブターゲットにCloud Pub/Subを選択すると、後述する実行コンピュートとなるCloud Functionsなどを実行することができる。なお、Cloud Scheduler からCloud Pub/Subに対して非同期になるが、Cloud Pub/Sub から Cloud Functionsなどの呼び出しの確認応答時間は最大 10 分であることを考慮する。また、Cloud Scheduler側では処理結果まで確認できないため、実行コンピュート側で処理ステータスの監視を行うこと推奨する。
60分以上の処理時間がかかる場合や、複数の処理を組み合わせる必要がある場合は、Workflowsの利用を検討する。
Workflows を使用すると、ワークフローの一部として Cloud Run ジョブを実行し、より複雑なデータ処理を行う、または既存のジョブのシステムをオーケストレートすることが可能となる。
[Google Cloudドキュメント：Workflows を使用して Cloud Run ジョブを実行する]
https://cloud.google.com/workflows/docs/tutorials/execute-cloud-run-jobs?hl=ja 既存システムでApache Airflowを使用している場合や、前述の推奨構成では要件を満たせない場合は、Cloud Composerの利用を検討する。
[Google Cloudドキュメント：サービスオーケストレーション用のワークフローまたは Cloud Composer を選択する]
https://cloud.google.com/workflows/docs/choose-orchestration?hl=ja 以上のサービス選択だとアプリケーションの変更が必要な場合はCompute Engineの利用を検討する。
[Google Cloudドキュメント：Google Cloud での適切なオーケストレーターの選択]
https://cloud.google.com/blog/ja/topics/developers-practitioners/choosing-right-orchestrator-google-cloud | 検討ポイント１ | 検討ポイント２ | サービス | | --- | --- | --- | | 単一処理 | ・ジョブターゲットにCloud Pub/Subの選択が可能(実行コンピュートとの連携が可能)で10分以内に処理が完了する
・ジョブターゲットにHTTPを選択し30分以内に処理が完了する | Cloud Scheduler | | 複数処理の組み合わせ
もしくは完了に60分以上がかかる処理 | ・同じワークフローの同時実行する
・並列ステップを使用したワークフロー内の実行を行う
・Cloud Run ジョブを実行することで最大24時間までの長時間実行が可能 | Workflows | | | ・既存システムでApache Airflowを使用している
・マルチクラウド/オンプレミスにまたがるパイプラインを展開する
・ETL/ELTワークフローを使う | Cloud Composer | ### 実行コンピュート検討のポイントコンピュート環境はサーバーレス環境での実⾏を優先的に検討することが推奨される。
Cloud Functionsで要件が満たせるワークロードの場合、Cloud Functionsの利⽤が推奨される。なお、Cloud Functionsの利用には第2世代を選択することを推奨する。以下、Cloud Functionsに関する記述は全て第2世代を指す。
[Google Cloudドキュメント：Cloud Functions バージョンの比較]
https://cloud.google.com/functions/docs/concepts/version-comparison?hl=ja#comparison-table Cloud Functionsで要件が満たせない場合においてはなるべくコンテナ化を⽬指し、Cloud RunやGKEの利⽤を検討する。
Cloud Run サービスを利用する場合、1インスタンスあたりの同時実行数について、コンテナの CPU 使用率/コンテナのリクエストカウント/コンテナのインスタンス数を考慮する。
[Google Cloudドキュメント：Cloud Run 全般的な開発のヒント]
https://cloud.google.com/run/docs/tips/general?hl=ja
Cloud Run ジョブを利用する場合、タスクの再起動で出力が重複したり、破損しないように、ジョブをべき等にすること。また、ジョブにチェックポイントを設定することで、障害発生後にタスクが再開したときに、タスクを最初からではなく、中断したところから再開できる。
[Google Cloudドキュメント：Cloud Run ジョブの再試行とチェックポイントのベストプラクティス]
https://cloud.google.com/run/docs/jobs-retries?hl=ja 24時間を超える長時間にわたって処理時間がかかる場合や、ステートフルな処理が必要となる場合、あるいは、他サービス・アプリケーションや既存システムでKubernetesを利用している場合は、実行コンピュートも併せてGKEの利用を推奨する。GKEを利用する場合、Google Cloud に備えられた柔軟性を活用し、コストが最適化されたアプリケーションの実装も考慮する。
[Google Cloudドキュメント：コストが最適化された Kubernetes アプリケーションを GKE で実行するためのベストプラクティス]
https://cloud.google.com/architecture/best-practices-for-running-cost-effective-kubernetes-applications-on-gke?hl=ja Cloud RunとGKEの検討ポイントについては下記の公式ドキュメントを参考にすること。
[Google Cloudドキュメント：GKE と Cloud Run、どう使い分けるべきか]
https://cloud.google.com/blog/ja/products/containers-kubernetes/when-to-use-google-kubernetes-engine-vs-cloud-run-for-containers 上記サービスで要件が満たせず、以上のサービス選択だとアプリケーションの変更が必要な場合はCompute Engineの利用を検討する。
[Google Cloudドキュメント：どこで実行すべきか。Google Cloud のコンピューティングオプションの選択]
https://cloud.google.com/blog/ja/topics/developers-practitioners/where-should-i-run-my-stuff-choosing-google-cloud-compute-option なお、どの実行コンピュートで実装する場合も、費用の最適化も併せて考慮する必要がある。下記のGoogle Cloud公式ドキュメントを参考にすること。
[Google Cloudドキュメント：費用の最適化コンピューティング、コンテナ、サーバーレス]
https://cloud.google.com/architecture/framework/cost-optimization/compute?hl=ja また、将来データ分析のためにETL処理・データ処理を行う場合、他のGoogle Cloudリソースとの親和性が高いDataflowの利用を推奨する。Dataflowでは、JavaやPythonで処理を作り込むことも可能であるが、Googleが標準で提供しているテンプレートを使うことも可能である。
[Google Cloudドキュメント：Dataflow テンプレート]
https://cloud.google.com/dataflow/docs/concepts/dataflow-templates?hl=ja ※補足
より長い時間の処理となる場合のオプションは下記の通り - Workflows で Cloud Run を起動する（参照URL：https://cloud.google.com/workflows/docs/reference/googleapis/run/Overview) - Workflows で Compute Engine を起動する（参照URL：https://cloud.google.com/workflows/docs/reference/googleapis/compute/Overview） - Workflows で Dataflow を起動する（参照URL：https://cloud.google.com/workflows/docs/reference/googleapis/dataflow/Overview） | 検討ポイント１ | 検討ポイント２ | サービス | | --- | --- | --- | | Cloud Functionsでサポートされるプログラミング言語/ツールのみで実装可能
(https://cloud.google.com/functions/docs/runtime-support?hl=ja) | ・HTTPでトリガーされる処理で60分以内に完了する
・イベントドリブンの処理で9分以内に完了する
・サブタスクに分割が可能である |Cloud Functions | | Cloud Functionsでサポートされないプログラミング言語/ツールが必要 | ・HTTPでトリガーされる処理で60分以内に完了する
・コンテナ化が可能である
・サブタスクに分割が不可能である | Cloud Run サービス | | | ・Workflowsを利用したワークフローの一部としての実行
・Cloud Schedulerによるスケジュールに沿った実行
・コンテナ化が可能である | Cloud Run ジョブ | | | ・他サービス/アプリケーションや既存システムでKubernetesを利用している
・ステートフルなアプリケーションを利用する
・24時間を超える長時間の処理実行 | GKE | | 以上のサービス選択だとアプリケーションの変更が必要になる | |Compute Engine | | ETL処理・データ処理を行う | 将来データ分析を行う予定がある | Dataflow | ### 各サービスの詳細 **オーケストレーション/スケジューラー** | サービス | 詳細 | 公式ドキュメント | | --- | --- | --- | | Cloud Scheduler | 作業単位のスケジュールを設定して、定義した回数または一定の間隔で実行できる。
Cloud Scheduler を使用して作成された各 cron ジョブは、指定のスケジュールに従ってターゲットに送信される。 | https://cloud.google.com/scheduler/docs/overview?hl=ja | | Workflows | フルマネージドのオーケストレーションプラットフォームで、定義した順序（ワークフロー）でサービスを実行する、サーバーレス且つ必要に応じてスケールアップするマネージドサービス。 | https://cloud.google.com/workflows/docs/overview?hl=ja | | Cloud Composer | フルマネージドのワークフローオーケストレーションサービス。
特定のベンダーに依存する必要がなく、ハイブリッドおよびマルチクラウド環境にまたがるパイプラインを作成、スケジューリング、モニタリングを実現することができる。 | https://cloud.google.com/composer/docs/concepts/overview?hl=ja | **実行コンピュート** | サービス | 詳細 | 公式ドキュメント | | --- | --- | --- | | Cloud Functions | スケーラブルな従量課金制 Functions as a Service（FaaS）プロダクトにより、サーバーやコンテナによる管理なしでクラウド上でコードを実行できる。 | https://cloud.google.com/functions/docs/concepts/overview?hl=ja | | Cloud Run
(サービス/ジョブ) | スケーラブルなインフラストラクチャ上でコンテナを直接実行できるマネージドコンピューティングプラットフォーム。 | https://cloud.google.com/run/docs/overview/what-is-cloud-run?hl=ja | | GKE | Google のインフラストラクチャを使用して、コンテナ化されたアプリケーションのデプロイ、管理、スケーリングを行フルマネージド Kubernetes サービス。 | https://cloud.google.com/kubernetes-engine/docs/concepts/kubernetes-engine-overview?hl=ja | | Compute Engine | Google のインフラストラクチャ上で仮想マシンを作成して実行できる、コンピューティングおよびホスティングサービス。 | https://cloud.google.com/compute/docs/instances?hl=ja | | Dataflow | サーバーレスかつ高速で、費用対効果の高い、統合されたストリームデータ処理とバッチデータ処理を行う。 | https://cloud.google.com/dataflow/docs?hl=ja | ## イベントドリブン化
### イベントドリブン処理の必要性について従来のオンプレミスシステムでよく存在していた夜間バッチアプリケーションについては、夜間バッチ処理の処理負荷を分散するために夜間のシステムの停止（閉局）が必要になったり、夜間のジョブの監視要員が必要になったり、バッチ処理が失敗したときに朝のシステムの開始（開局）までのリカバリーが困難であるなど、システム運用の難度を上げる大きな要因であった。これを廃止もしくは極小化することを目指し、更新イベントがあるたびに後続処理を行う、イベントドリブン処理とすることでシステム運用のシンプル化を進めることを推奨する。また、夜間バッチアプリケーションを廃止・極小化することで、複雑なジョブ連携をジョブフローとして管理するジョブ管理サーバも不要となる。 ### イベントドリブン処理の基本的な構成要素これまでの夜間バッチ処理をイベントドリブンな処理に変更する際に、基本的な構成要素がどのようになるかを以下に解説する。リクエストの呼び出しイベント、処理の完了イベント、データの変更イベントなどの状態の変化をイベント発行元（イベントプロデューサ）からイベントストア/ルーター/バスを通じて、後続の処理サービスへと伝播し処理を実装することができる。 | 構成名 | 概要 | 対応するサービス| | --- | --- | --- | | イベントプロデューサー | リクエストの呼び出しイベント、処理の完了イベント、データの変更イベントなどの状態の変化をイベントルータ等に伝える主体。 |様々なアプリケーション、モバイルをふくめた様々なチャネル、Google Cloudサービスが発行するイベント（処理完了、データ変更、状態変化等） | | イベントルータ／イベントストア／イベントバス | イベントを受信し、ルーティングする中継作業を行うコンポーネント。 |Cloud Pub/Sub、Eventarc | | イベントコンシューマ| イベント駆動で処理を起動する。イベント待ち受けの効率性/経済性を考慮すると、サーバーレスは良い選択肢になる。 | Cloud Functions、Cloud Run| ![図 02: イベントドリブンの構成要素](/images/gcp_know-how-replatform-migrate-operation-and-maintenance-02.png)
**図 02: イベントドリブンの構成要素**
（引用URL：https://cloud.google.com/eventarc/docs/event-driven-architectures?hl=ja) ### イベントドリブン処理のデザインパターンイベント駆動のジョブを作成するにあたって、代表的なデザインパターンとして以下の２種類のデザインパターンが存在する。ジョブを実装する際に、いずれかの方式を選択するというよりは、それぞれの方式を組み合わせて、イベント駆動のアプリケーションやジョブを構築することとなる。
[Google Cloudドキュメント：Google Cloud でのサービスオーケストレーション]
https://cloud.google.com/blog/ja/topics/developers-practitioners/service-orchestration-google-cloud | デザインパターン名 | パターンの概要 | | --- | --- | | サービスコレオグラフィー |各サービスは独立して動作し、イベントを通じて他のサービスと疎結合の状態で相互に作用する。
疎結合されたイベントは、独立して変更やスケーリングが可能なため、単一障害点が存在しない。しかし、サービス間で多くのイベントが飛び交っているため、モニタリングが非常に困難である。 | | サービスオーケストレーション | サービス間のすべてのインタラクションをコントロールする一元的なオーケストレーションによって、サービスが相互に作用する。
ビジネスプロセスの概要を示し、実行の追跡や問題のトラブルシューティングを行うことが可能となる。|
#### コレオグラフィ #### コレオグラフィの動きの概要コレオグラフィの動きとしては、必要なすべての情報を含んだ最初のイベントを1つのメッセージに保存して、最初のトランザクションを完了する。他のサービスがそのメッセージを非同期的に取得し、あらかじめ定められた動作条件（振付：コレオグラフィ）にしたがって、それぞれのタスクを完了させる動きとなる。これにより、サービスが疎結合になり、直接互いに影響を与えない構成となる。その結果として、イベントメッセージの保存と取得が非同期の関係になり、スケーラビリティと信頼性が向上する。 #### 実装例：Cloud Pub/Sub、Cloud Functionsの利用 - アプリケーションからリクエストを受けた「Cloud Pub/Sub」は、イベントプロデューサー（パブリッシャー）とコンシューマー（サブスクライバー）のシステムを作成。 - 「Cloud Functions」は「Cloud Pub/Sub」の「subscription」がメッセージを受信された際に、何らかの「Cloud Functions」関数を呼び出す。 - この場合、従来型のバッチ処理は「Cloud Functions」関数として実装することとなるが、マイクロサービスとなるように役割を決めて実装することを推奨する。なお、トピックをサブスクライブしている「subscription」が複数ある場合、「subscription」に紐づく「Cloud Functions」を並行的に実行（ファンアウト）することができる。 - この構成の利点としては、「リクエストサービス」は「Cloud Pub/Sub」のトピックにパブリッシュするだけでよく、バッチ処理などの記述は「Cloud Functions」関数のみで実装されている点である。すなわち、ロジックを意識せずにサービス結合ができ、疎結合な構成が可能である。
![図 03: コレオグラフィの実装例](/images/gcp_know-how-replatform-migrate-operation-and-maintenance-03.png)
**図 03: コレオグラフィの実装例図** #### オーケストレーション #### オーケストレーションの動きの概要オーケストレーションの動きとしては、特定の日時における単一サービスの単純な実行から、複数のサービスを長期にわたって自動的に実行してモニタリングしつつ、発生と同時に障害にも対処できるより高度なアプローチまで行うことができる。ビジネスプロセスを定義し、イベントドリブンなジョブやバッチジョブ、エラー処理のロジック、一連の操作など、複雑なプロセスの呼び出しをオーケストレートに行う。 #### 実装例：Cloud Storage、Cloud Functions、Workflowsの利用 - 作業者がデータを「Cloud Storage」にアップロードする。 - 「Cloud Storage」にアップロードされたことをトリガーとする「Cloud Storag トリガー」により「Cloud Functions」関数が実行される。(参考URL：https://cloud.google.com/storage/docs/pubsub-notifications?hl=ja) - 「Cloud Storage」にアップロードされたファイル名を「Workflows」に連携して動かす。 - 受け取った「Cloud Storage」のファイル名をもとに「Workflows」を実行する。 - 「Workflows」が実行され、後続の「Cloud Run」サービスの実行、及び「Cloud Pub/Sub」にメッセージを送信する。 - この構成の利点としては、1つの操作(トリガー)で複数サービスの呼び出しを実装している点である。アーキテクチャを簡素化し、複雑なサービス統合の可視化とモニタリングを行うことができる。 ![図 04: オーケストレーションの実装例](/images/gcp_know-how-replatform-migrate-operation-and-maintenance-04.png)
**図 04: オーケストレーションの実装例** 両実装例に利用している、Cloud Pub/Sub(イベントルータ／イベントストア／イベントバス)に関して下記の点に注意する。 - サブスクライバーがCloud Pub/Subに送る確認応答の期限(acknowledgment deadline)は最大10分である。 - 後続のCloud Functions や Cloud Run のリクエストタイムアウトをこの時間よりも短くする必要がある。 - Cloud Pub/Sub から Dataflow を呼び出す場合、PubSub I/O コネクタが、Dataflow のすべての処理が完了した時点ではなく、Cloud Pub/Sub から受領したメッセージを Dataflow 内のディスクへ永続化した時点で確認応答(acknowlegment)を返答するため acknowledgment deadline に抵触する可能性が低くなる。 - 呼び出された Cloud Functionsで問題が発生した場合、acknowledgment deadline を超過した場合は Cloud Pub/Sub はリトライを行うので、リトライが行われても正しく処理されるように冪等性を担保すること。
(参考URL：https://cloud.google.com/pubsub/docs/subscriber?hl=ja) - Cloud Pub/Sub は at-least-once でメッセージを配信するので、場合によっては重複してメッセージが配信されるため、重複して呼び出されても正しく処理が行われるように実装する必要がある。 - (実装例2のみ)Cloud Storageのバケット内のオブジェクトに変更が加えられるとその情報を Cloud Pub/Sub に配信されるが、配信の順序が保証されていないので、順序が異なっても正しく処理が行われるように実装する必要がある。 - Cloud Pub/Sub のメッセージを受ける Cloud Functions や Cloud Run に継続的に問題があると、Pub/Sub メッセージのリトライ上限を超えてしまう場合があり、デッドレタートピックを設定するなどしてリカバリ処理を実装する必要がある。
(参考URL：https://cloud.google.com/pubsub/docs/handling-failures?hl=ja#dead_letter_topic) # 監視の移行 ## 前提 ### Observabilityとは Observabilityが確保されているということは、システムの監視機能が以下を達成している状態を指す。 #### Observabilityの要件 1. 問題発生時にアラームを発報し人へ介入を促す。 2. 問題発生時に原因を調査するために必要な情報を提供する。 3. 長期的な計画を立てるために必要となる情報（サービスの状態とリソース消費量の傾向）を提供する。 4. 更新がデプロイされる前後、又は二つの異なるバージョンを比較するための情報を提供する。 5. これらの情報のうち重要なものを視覚的に表示する。これらの目標を達成するためにシステムの監視機能は以下3種類のデータを収集する必要がある。 - メトリクス: 特定の時刻に計測されたシステム状態を現わす数値 - ログ: システム内で発生したイベントの記録 - トレース：複数サービスを横断して連鎖的に発生したイベントの記録 ## 監視移行の方法論 ### 監視対象についての考え方システムに異常が発生しているかを判断するためには最低限以下の項目を監視すべきである。 - レイテンシー（Latency） - 各サービスがリクエストの応答にかかる時間を計測したもの。成功時応答とエラー時応答のレイテンシーはそれぞれ個別に集計され統計値を算出すべきである。これは、例えば瞬時に応答が返るエラーがある場合、成功時応答とエラー時応答を混同した平均レイテンシーなどの統計値は有益な情報をもたらさないからである。 - トラフィック（Traffic） - 各サービスの需要を計測したもの。例えばHTTPベースのAPIサービスであれば秒間HTTPリクエスト数がトラフィックにあたると考えられる。ストリーミングサービスの場合、同時接続数がトラフィックを現わすメトリクスとしてより適切である。 - エラー（Errors） - ユーザーが期待される結果を返せないという事象。これは5XXエラーが発生した場合のみならず、HTTPコードは200だが応答内容が正しくない場合や許容範囲外のレイテンシーを要した場合など、ユーザーが期待する結果を返せない状態全てを意味する。単純なロードバランサーの5XXエラーコード数カウントだけでは不十分なことが多く、ユーザー視点から期待値と結果の整合性を担保する外形監視の導入が推奨される。 - 飽和度(Saturation) - 各リソースの配置済み容量の内、使用中の割合を示したもの。各サービスのボトルネックとなる可能性が高いリソースほど飽和度監視の優先度が高い(例：CPU使用率に応じてオートスケーリングするサーバークラスタのメモリ使用率)。反対に、ボトルネックになりにくいリソースは優先度が低い(例：CPU使用率に応じてオートスケーリングするサーバークラスタのCPU使用率)。 ### 監視を実現するためのGoogle Cloudサービス監視の実現するサービスはそれらが達成するObservabilityの要件（参照：**Observabilityとは**）に応じて、以下の３種類に分類される。 1. 計測・通知を行うサービス(1を達成) - 計測手段: Cloud Monitoring、Cloud Logging、Cloud Trace、Security Command Center、Cloud Audit Logs、Cloud Billing - 連携・通知手段: Cloud Monitoring(通知チャンネル)、Cloud Pub/Sub、Cloud Functions 2. ログ・メトリクスデータを保管するためのサービス(2と3を達成) - Cloud Storage、Cloud Logging、BigQuery 3. 可視化を行うサービス(2、4と5を達成) - Cloud Monitoring、Cloud Billing #### 計測通知を行うサービス **計測手段** | サービス | 詳細 | 公式ドキュメント | | --- | --- | --- | | Cloud Monitoring | アプリケーションとインフラストラクチャのパフォーマンス、可用性、健全性を可視化できる。 | https://cloud.google.com/monitoring/docs/monitoring-overview?hl=ja | | Cloud Logging | エクサバイト規模で行われるストレージ、検索、分析、アラートを備えたフルマネージドでリアルタイムなログ管理サービス。 | https://cloud.google.com/logging/docs/overview?hl=ja | | Cloud Trace | アプリケーションのすべてのトレースを自動的に分析し、パフォーマンス低下の原因となるレイテンシの詳細を分析できる。 | https://cloud.google.com/trace/docs/overview?hl=ja | | Cloud Profiler | 本番環境のアプリケーションのリソース消費を継続的にプロファイリングする。 | https://cloud.google.com/profiler/docs/about-profiler?hl=ja | | Security Command Center | 脆弱性と脅威の報告を一元的に行うセキュリティおよびリスク管理プラットフォーム。 | https://cloud.google.com/security-command-center/docs/concepts-security-command-center-overview?hl=ja | | Cloud Audit Logs | 管理アクティビティと Google Cloud リソース内のアクセスを記録する監査ログ。 | https://cloud.google.com/logging/docs/audit?hl=ja | | Cloud Billing | Google Cloud の費用の追跡と把握、料金の支払い、費用の最適化に役立つツールコレクション。 | https://cloud.google.com/billing/docs/concepts?hl=ja | **連携・通知手段** | サービス | 詳細 | 公式ドキュメント | | --- | --- | --- | | Cloud Monitoring(通知チャンネル) | アラートポリシーが起動したときに通知チャンネルを使って通知することが可能。通知チャネルな複数作成が可能。 | https://cloud.google.com/monitoring/support/notification-options?hl=ja | | Cloud Pub/Sub | メッセージを生成するサービスを、それらのメッセージを処理するサービスと切り離す、非同期のスケーラブルなメッセージングサービス。 | https://cloud.google.com/pubsub/docs/overview?hl=ja | | Cloud Functions | スケーラブルな従量課金制 Functions as a Service（FaaS）プロダクトにより、サーバーやコンテナによる管理なしでクラウド上でコードを実行できる。 | https://cloud.google.com/functions/docs/concepts/overview?hl=ja | 以下の図に示されるよう、ログやメトリクスはCloud Monitoringの通知チャンネルで通知するか、Cloud Pub/SubとCloud Functionsを使って通知先にメッセージを連携する。 ![図 05: 監視の全体像](/images/gcp_know-how-replatform-migrate-operation-and-maintenance-05.png)
**図 05: 監視の全体像** #### ログ・メトリクスデータを保管するためのサービス | サービス | 詳細 | 公式ドキュメント | | --- | --- | --- | | Cloud Storage | 非構造化データを保存するためのマネージドサービス。 | https://cloud.google.com/storage/docs/introduction?hl=ja | | Cloud Logging | フルマネージドのログ管理サービスで、ログデータを保存して整理するためのコンテナとしてログバケットを使用できる。 | https://cloud.google.com/logging/docs/routing/overview?hl=ja#buckets | | BigQuery | 完全にサーバーレスで費用対効果に優れたエンタープライズデータウェアハウス。 | https://cloud.google.com/bigquery/docs/introduction?hl=ja | #### 可視化を行うサービス | サービス | 詳細 | 公式ドキュメント | | --- | --- | --- | | Cloud Monitoring | アプリケーションとインフラストラクチャのパフォーマンス、可用性、健全性を可視化できる。 | https://cloud.google.com/monitoring/dashboards?hl=ja | | Cloud Billing | Google Cloud の費用履歴、現在のコスト傾向、コスト予測を可視化することができる。 | https://cloud.google.com/billing/docs/reports?hl=ja | ### 通知についての考え方システムの監視機能はメトリクス、ログ、トレースを元にシステムの状態を継続的に診断する。異常が検知された場合、システムは人へ介入を促す必要がある。通知方法には問題の緊急度に応じて以下の３つに分類される。 - ページ: 即時対応が必要 - チケット:　数日以内に対応が必要 - ロギング:　対応は不要だが記録として残す(自動修復により解決された場合など) ページは即時対応が必要な事象が発生した場合に可能な限り厳密に限定する必要がある。即時対応が不必要にも関わらずページされるという事象が多発した場合、運用管理者へ不必要な負担をかけてしまうだけでなく、実際に緊急度の高いページが発生した場合に運用管理者が適切な緊張感を感じなくなってしまう可能性がある。また一度発生したページは可能な限り再発しないよう、根本的原因の解決や対応の自動化を検討する必要がある。
なお、連携・通知手段に関しては冗長性確保のため、複数の通知チャネルを作成することを推奨する。Cloud Monitoringの通知チャンネルは複数オプションを提供しているので、Slack・Webhook・PagerDutyでダイレクトに通知先に連携したり、メール・SMS・Cloud Pub/Subで既存システムとのAPI連携を行うことを検討する。
[Google Cloudドキュメント：通知チャンネルを作成する]
https://cloud.google.com/monitoring/support/notification-options?hl=ja#creating_channels 問題の緊急度の高さはシステムによって異なるが、ユーザーへの直接的な影響が発生している場合はページ通知が適切な場合が多い。以下に各異常の通知方法の分類の一例を示す。 **通知方法の分類例** | 状態 | 通知方式 | 理由 | | --- | --- | --- | | 5XXエラーが多発している | ページ |　ユーザーが期待する結果をサーバーが返せていない可能性が高いため | | 各リクエストへのレスポンスタイムが正常値を大幅に超えている | ページ | ユーザーが直接感じることができる異常のため | | サーバーCPU使用率が100%になった | チケット | オートスケーリングが正しく機能していないなどの異常がある可能性は高いが、ユーザーへの直接的影響を計る指標ではないためチケットが適当である。
ユーザーへの直接的影響が発生している場合、レスポンスタイムの監視によりページ通知がされるため、本項目はチケットで十分である。 | | 毎週末実行されるバックアップジョブが失敗した | チケット | バックアップが失敗しても、ユーザーへ直ちに影響は発生しないためページは適当でない。しかし失敗の原因分析やバックアップの再試行が必要なためチケットが適当。 | | ヘルスチェックに失敗したインスタンスが置換された | ロギング | 自動修復により解決され人が介入する必要はないため | | 4XXエラーが少量発生している | ロギング | ４XXエラーは主にクライアント起因のエラーのため、サーバーが正常な場合でも発生することがあり、少量であれば問題があるとは考えられないため | なお上記は通知方式の分類例の一例であり、すべてのシステムにおいて必ずしも上記の例が最適であるとは限らない。 ## 改訂履歴 | 改訂年月日 | 改訂理由 | | ------------------- | -------- | | 2023 年 03 月 27 日 | 新規作成 | | 2024 年 02 月 02 日 | Cloud Run JobsとWorkflows前提とした構成に変更 |

Replatformシステム移行ノウハウ（運用のマネージドサービス化）(Google Cloud編)