メルペイでの運用環境とオブザーバビリティ
この記事は、Merpay Advent Calendar の14日目の記事です。
こんにちは。メルペイのSettelementチームで開発を担当するバックエンドエンジニアの @shiv3 です。
9月に入社後今のチームへ配属されてからシステムのキャッチアップが進み、晴れて開発している担当のシステムのオンコール当番を任されるようになりました。
「メルペイSREチームのこれまでとこれから」でも触れられていますが、メルペイではSREチームがオブザーバビリティやオンコール制度を整えてくれており、開発チームと協力体制でオンコールを回しています。
オンコール体制で重要になるのは、オンコール担当者のシステムへの理解やドメイン知識は言うまでもなく、アラートが鳴った際にすぐに原因調査を行える状態にしておくことが重要です。安定したシステムでも、もし何か起こった際に原因が全く分からないブラックボックスの状態では安心して運用できないため、原因調査の手段は日頃から備えておく必要があります。
今回は実際にメルペイでの運用にあたって、運用時にどのようなツールが使われているかについて紹介したいと思います。
オブザーバビリティ
Observability(可観測性)とは、システムに何かが起こった際、起こっていることをどれだけ把握できるか、その根拠を示す有用なデータを収集する能力を示すものです。
よく「モニタリング」という言葉と対比されますが、「モニタリング」という用語は主にメトリクスの収集やアラートに対して使われます。システムのパフォーマンス指標を監視しシステムの異常な動作を示す信号があった場合に警告を発するようなプロセスを指します。
それに対しオブザーバビリティは、モニタリングの上位概念です。システムの健全性を提供するだけでなく、システムの内部状態に関するコンテキストを把握します。可用性やパフォーマンスに関する問題のトラブルシューティングを行い、より深いシステムの問題を理解することを目的としています。
オブザーバビリティを向上させるメリット
オブザーバビリティは、障害に対しては防災グッズのようなもので、備えておくことでいざというときに役立ちます。また、障害時のトラブルシューティングだけでなく、複雑なシステムの理解や、アプリケーションのパフォーマンスやサービス品質を高めるために利用できます。リグレッションテストやQAでのテスト時にも役立ちます。
メルペイでの運用時に用いる情報・ツール
メルペイでは大規模な分散システムの上で高レベルな可用性とセキュリティが求められるサービスが動いています。それらの運用を以下のサービスを使って行っています。
Datadog
メルペイでは主にシステムの監視にDatadogを使っており、Kubernetesのクラスタ上でDatadogのエージェントを稼働させることで各種メトリクスやログをDatadogに集約しています。こちらの記事でも紹介された各機能を利用しています。また、新しくマイクロサービスを作る際はmicroserivces-starter-kitを使うことで、DatadogのダッシュボードやPagerDutyの設定、Slackのグループまでもが自動で作られるようになっています。Datadogの主な機能については以下のように使っています。
- Dashboard
- 前述のmicroserivces-starter-kitによって自動的に各マイクロサービスのダッシュボードが作成されます。
- 各ダッシュボードでマイクロサービスのPod数やSpannerのnode数、gRPCのメトリクスなどを確認することが出来ます。
- メトリクス
- ログやgRPCのミドルウェアなど、全社的に共通利用するためのライブラリが用意されており、そちらを用いることで自動的にDatadogに各種デバッグや監視に必要なメトリクスを送信することが出来ます。
- APM
- ほとんどのマイクロサービスがAPMを設定しており、サービス間でのリクエストのトレースを行うことが出来ます。
- SLOのモニタリング用途にも用いており、前述の全社的なライブラリを使ってログとトレースのインテグレーションが出来るようになります。(これを行ってくれる)
- Service Mapなどの生成を行うことができ、それぞれのサービス間のレイテンシやエラーレートを確認することもできます。
- ログ
- 障害対応時に一番手がかりとなる情報で、エラーの詳細情報やそのエラーを特定するための情報を出しておきます。
- メルペイの決済マイクロサービスでは各トランザクションに対してリソースIDを発行しており、それを一緒に出すことで一連の処理の流れを追いやすくしています。
- zapなどの構造化ロギングライブラリを使用しており、前述のようにAPMのトレース情報と紐付けて扱うことも出来ます。
Slack通知
DatadogのSlackインテグレーションとDatadogのモニタリングを用いてしきい値を越えた際にSlackに通知をする仕組みを導入しています。
Slackインテグレーションはインシデント対応時にインシデント用の一時的なチャンネルを作ったり、不必要なアラートをミュートしたりする機能が便利です。
そのほかにもバッチの実行結果の正常系や異常系などを定期的に流したり、エラーログなどをSentry経由でPagerDutyに連携してアラートを鳴らす仕組みなども行っています。
運用社内ツール
オブザーバビリティの観点とは少し異なりますが、運用を行う上で本番環境のデータにアクセスする必要がある場合があります。その際は以下のような社内ツールを利用しています。
gchammer
「Spanner にクエリをレビューして実行する gchammer」で紹介しているgchammerは本番環境に対してセキュアにクエリを実行するためのツールです。開発者は本番環境のデータに直接アクセスする権限がありませんが、こちらのサービスを利用することでレビューを受けたクエリのみ実行することが可能です。
ops-bot
gchammerの記事にあるように、gchammerはクエリを実行するたびに都度レビューが必要になるのですが、緊急対応時などによく使用されるクエリのテンプレートを予め定義しておき、Slack実行できるbotがあります。Work Hard to Be Lazy With ChatOpsでも紹介がありますが、クエリを直接記述できず、開発者によってレビューされたクエリのみを実行できます。実行結果は、開発者のみの権限が付与されたGoogleスプレッドシートまたはSlackメッセージで返されます。
それぞれのツールを使って運用してみて
メルペイではSREチームや社内の基盤、ライブラリを作ってくれているチームのおかげで、環境に予め設定やツールが整備されており、開発者は開発や改善タスク、運用に集中できるようになっていると実感しました。
また、実際に複雑なドメインとマイクロサービスを運用する上では、podなどのインフラの情報などだけではなく、各マイクロサービスの状態を理解する上で必要な情報を出しておく必要があります。
開発者がオブザーバビリティを向上させるために
適切なデータを生成する
オブザーバビリティの3つの柱としてログ・メトリクス・トレースの3つが上げられることが多いですが、これらはオブザーバビリティを高めるための手段であり、これら3つを出しておけば必ずオブザーバビリティが向上するというわけでもありません。以下のような観点を考えながら設定しておく必要があります。
- そのメトリクス情報からシステムの状態を説明出来るのか？
- 障害が起こった際に必要なログは出せているか？
- 障害時のログを見て原因を特定出来るか？
監視ツールの適切な使用方法のスキルを身につける
優れたデータや監視ツールがあっても、適切な使い方が分からない場合はほとんど意味がありません。また、担当するマイクロサービスやチームによっても適切な使用方法は異なる場合があります。チームや組織で使っているツールや障害対応時の調査手順などについて、使いこなすスキルをチーム内で共有しておく必要があります。
定期的にフィードバックを行う
常にアップデートをしているシステムでは、当初の目的と異なるメトリクスやログの出力になるケースがあり、運用上そのデータで問題の特定が出来るのかなどを見直す必要があります。
まとめ
Observableなシステムは、単にモニタリングされているだけでなく、SREチームに任せきりでは達成できるものでもありません。
また、単なるAPMやモニタリングの導入ではなく、テストや障害対応時などに必要な情報にどうアクセスするかというプロセス自体に意味があり、それらを解決するために何の情報が必要なのかというフィードバックをすることでよりオブザーバビリティの高い環境が出来るようになると思います。
オンコール当番中でも安心して寝れるよう、開発者としてもシステムのオブザーバビリティを向上させていければと思っています。
