ACESのソフトウェアエンジニアの稲田です。私は普段、弊社で提供しているシステムのアーキテクト設計、MLOpsをメインに担当しております。 今回は、ACES Meetという弊社のAIプロダクトサービスをターゲットに弊社のサービス監視基盤を標準化した話について、事例紹介をしたいと思います。
営業支援AIツール「ACES Meet」
想定する読者
- マルチアカウントで複数サービスの監視運用を考えている管理者
- 複数の AWS アカウント環境下でManaged Grafanaを利用するメリットを知りたいヒト
- プロダクトの監視を楽にしたいヒト
プロダクトサービスの品質可視化の重要性について
サービスの信頼性を維持・向上させるためには、まず、サービスのシステム品質を可視化することが大切です。
例えますと、健康診断の定期健診のように、定点で確かなメトリクスで体の状態を細かくチェックするのが大事なのに似ています。症状が出るまでほっておいて調べてみた時にガンのStage4では遅いのです。
プロダクト監視のあるべき姿は、
- サービス品質を表現するメトリクスが定義されダッシュボードに可視化されている
- 障害発生時にどこで何が起きたか素早く確実に把握するために必要となる全てのシステムメトリクスを一つのダッシュボードで網羅的に見れるようになっている
- 日々の経年の変化を継続的に見ることで、傾向から障害の早期検知を行い障害を未然に防げるようになっている
このような監視ダッシュボードがあり、サービス品質を表現するメトリクスが閾値を超えたら自動でアラート通知が飛んでくるようになっているのがあるべき姿です。
弊社が抱えていた課題と背景
これまで弊社はSentryをベースにB2Bプロジェクトの提供サービスの障害監視を行っておりました。
また、これまで商用プロダクトサービスは展開しておらず、ACES Meetを昨年末β版提供でデモ利用を頂いておりましたが、正式リリースに向けて、商用に耐え得る、安心してお客様にご利用して頂けるサービスのプロダクト監視基盤の整備が急務となっておりました。
ただ、ACES Meetは3月正式リリース予定のサービスで(現時点ではリリース済)、監視基盤構築にかけられる時間は必ずしも潤沢にあるとは言えない状況でした。
弊社はセキュリティ設計上の観点で、顧客/プロダクト毎にAWSアカウントを発行して運用しており、作った監視基盤が専用のプロダクトでしか使えないものではなく、新しいサービスを構築した時にAWSマルチアカウント環境で簡単に水平展開出来るようにしておきたいと考えておりました。
技術選定の方針
そのような背景から、まずは手軽に、監視要件に対して全てを満たすシステム基盤をはじめから作ろうとするのではなく、スモールスタートではじめたいと思いました。 というのも、監視基盤のソリューションとして代表的にDatadogやMackerel等のSaaSもあると思うのですが、外部サービスを使うと構成が複雑になり、外部サービスに引きずられて後で後悔するというのは避けたいと言う気持ちがありました。スモールにスタートしておけば、実際のプロダクトが成熟してサービスレベル目標(SLO)による監視要件が明らかになった時に、必要に応じて外部サービスを使う構成に拡張できます。
AWSだけでスモールにとなると、監視基盤の技術選定としては、 「CloudWatch + Xray (+ Prometheus)でメトリクス収集を行い、Grafanaを可視化ダッシュボードとして利用する」 ぐらいで良さそうです。 AWSが標準で提供しているダッシュボードではなく、Grafanaを可視化ツールとして使うことを選定したのは、私自身がGrafanaを前職で使い慣れていて可視化ツールとして優れている点を理解しており、また、AWSが標準で提供しているダッシュボードは使いにくい印象があったためです。 Amazon Managed GrafanaをサーベイしてAWSマルチアカウントで使いやすいサービス設計になっていることがわかったのもGrafana選定を後押ししました。
結果、普通すぎて少し退屈な感じではありますが、技術選定としては一旦この通りとして走り始めました。 監視基盤の技術選定のおおまかな方針が決まり、以下の通り監視基盤設計を行いました。
プロダクト監視基盤設計
目的
プロダクトの標準監視ダッシュボードを作成し、サービス品質を可視化します。
- サービス品質を表現するモニタリング測定値(SLI)の定義と可視化
- 異常早期検知と原因特定のためのシステム詳細メトリクスの可視化
- 異常状態の定義とアラート通知
- リクエスト処理ボトルネックの特定のため、リクエスト単位でどこで処理に時間がかかっているか可視化
要件
- メトリクスの収集
- AWSマルチアカウントに対して一元的にメトリクス収集が可能であること
- メトリクスの保存期間は13カ月 (ここはCloudWatchのメトリクス保存期間の制約にあわせる)
- メトリクスの集計
- レートの計算、SLIの算出
- キー項目でのグループ化(API毎の集計、テナント毎の集計）
- 時系列データの時間単位(BIN)のグループ化(最小、最大、平均、パーセンタイル)
- メトリクスの監視
- SLIが閾値を下回った時、特定監視イベント発生時のアラート通知 (Slack/SMS)
- メトリクスの可視化
- 性能要件
- 内部サービスのため監視ができる範囲の最低限の性能が出れば良い
- 拡張性要件
- 新しいプロダクトが追加された時に、プロダクトを監視するための定義がテンプレート化されていて追加しやすいようになっている
- 運用要件
- プロダクト内で動的に生成される監視対象インスタンスの監視登録/削除の自動化
監視項目
サービス品質
- リクエストエラーレート
- リクエストレンテンシ (平均, 90パーセンタイル, 95パーセンタイル)
- バッチエラーレート
- バッチ処理時間 (平均, 最大)
- API毎のリクエスト数、エラーレート、レイテンシ
システム詳細メトリクス
| AWSサービス | 監視項目 |
|---|---|
| ALB | RequestCount, SurgeQueueLength, HTTPCode_ELB_5XX, Latency, HealthyHostCount, UnHealthyHostCount |
| Fargate | CPU, Memory, Network In/Out, Storage Read/Write |
| SQS | NumberOfMessageReceived, NumberOfMessageReceived(DLQ) |
| Sagemaker | CPU, Memory, Disk, GPU, GPUMemory, Invocations, Invocations4xxErrors, Invocations5xxErrors, ModelLatency |
| AWS Batch | CPU, Memory, Disk (*1) |
| RDS | CPU, FreeStorageSpace, DatabaseConnections, ReadLatency, WriteLatency, DiskQueueDepth |
| ElasticSearch | CPU, JVMMemoryPressure, FreeStorageSpace, ClusterStatus, ClusterIndexWritesBlocked, 2xx, 5xx, IndexingLatency, SearchLatency |
*1: AWS Batchのキューの状態はAWSデフォルトのメトリクスではサポートされないため、AWS公式の実装を参考に自分でカスタムメトリクスを出力する必要があります。
参考記事
AWS公式 ECS Container insights 取得できるメトリクス
AWS公式 RDS監視項目
AWS公式 ElasticSearch監視項目
aws-samples/aws-batch-runtime-monitoring: Serverless application to monitor an AWS Batch architecture through dashboards.
アラート通知
リクエストエラーレート、レイテンシのサービス毎に設定した閾値を下回った場合に通知します。
各々の死活監視は全てリクエストエラーレート、レイテンシに現れるため、個別のインスタンス、コンポーネントシステムの死活監視のアラート設定は基本行わない想定です。
エラー発生時、エラー原因がすぐ確認できるようになっていれば良しとします。
但し、以下は例外で個別にアラート通知するようにしました。
- AWS Batch JobFail (ACES Meetの監視ユースケースとして全ての推論Batchを正常完了させる必要があるため)
- ElasticSearchの推奨項目監視 (ElasticSearchは表面上は動いていても例えば裏でレプリカが落ちている状態でインスタンスが落ちるとデータが消失してしまい、データ復旧には時間がかかりサービスへの影響が大きいため)
システム構成
監視ダッシュボードの仕組み
監視ダッシュボードは、ログ、メトリクス、トレースという別々のデータソースからデータを取得して表示します。
表示部分はGrafanaが担当しますが、Grafana自体はデータは保持せず表示するだけで、データソースとしてとして、ログはCloudWatch Logs、メトリクスはCloudwatch Metrics、トレースはX-Rayから取得します。
各々のデータソースは以下の通り性格が異なります。
引用元：[レポート] Application Performance Management (APM) on AWS
| データソース | データ取得可能期間とメトリクス表示速度 |
|---|---|
| ログ (CloudWatch Logs) | ログから毎回メトリクスを作るため、メトリクスの表示速度がログ量に比例し、長期間の表示には時間がかかるため長期間の表示には向かない |
| メトリクス (Cloudwatch Metrics) | 表示速度が高速で、長期間のメトリクス表示が高速に行え長期間の傾向も高速につかめる。AWSが基本的なメトリクスはデフォルトで用意してくれている(ただ、全てのメトリクスはサポートされておらず、例えばAWS Batch等はメトリクスサポートがない)。また一方で、カスタムのメトリクスを作るのは実装が必要となるためメトリクス毎に*Nでインフラ実装工数が必要となる |
| トレース (X-Ray) | データを取得できる期間の範囲が最大6時間までで、長期間の傾向は見れない。アプリケーションにエージェント組み込みの実装が必要となり、初期コストとしてアプリケーションへの組み込み実装工数が1回だけ必要となる |
参考記事
AWS X-Ray トレーシング入門
AWS X-Ray とは？
Amazon Managed GrafanaのAWSマルチアカウントのデータソースサポート
Amazon Managed Grafanaは、AWS Organizationが裏でうまく活用されていて、複雑な設定不要でコンソールからセットアップ後、Grafanaからすぐデータソースとしてorganizationに属しているAWSアカウントのデータソースを追加可能です。
CloudWatchのメトリクスを他のAWSアカウントから見れるようにしたり、他のAWSアカウントにエクスポートしたり、マルチアカウントのIAM Roleの設計をしたりというマルチアカウントで発生する面倒な作業が一切なくmanagedでAWSが隠蔽してやってくれるので快適です。
以下のようにGrafanaからAWSアカウントを選んでデータソースを追加するだけで良いです。
Amazon Managed GrafanaのX-Rayサポート
Amazon Managed GrafanaはデータソースとしてX-Rayプラグインをデフォルトでサポートしており、X-RayのServiceMapをGrafanaの一つのパネルとして統合可能で、障害発生時にどこで何が起きたか素早く確実に把握するための強力な可視化メトリクスを監視ダッシュボードに提供してくれます。
引用元：[YouTube] Set Up AWS X-Ray as a Data Source Plugin for Amazon Managed Grafana | Amazon Web Services
同じものを作れば障害時の障害ノード特定が迅速に行える監視ダッシュボードが実現できますので、ありがたくまるっとコピーさせて頂きました。
監視ダッシュボードのデータソースの拡張性
弊社初期構成ではPrometheusはデータソースとして除外しましたが、監視メトリクスのデータソースとして Prometheus / AWS Timestream / ElasticSearch等、比較的柔軟に多種多様なデータソースを追加可能である点は魅力です。
コスト概算
CloudWatch
AWSデフォルトで提供しているメトリクスは無料、カスタムメトリクスは10,000メトリクスまでは1メトリクスあたり月$0.3です。 プロダクト監視基盤設計の「監視項目」の節で対象としたメトリクスを取得するためにはECS/ContainerInsightsを有効にする必要があり、その場合自動でカスタムメトリクスが作成されます。 コスト感はサービスの規模にもよりますが、AWS公式のAmazon CloudWatchの料金の例を意識しておくと良いと思います。
この料金とは別に、監視ダッシュボードを見た時に都度X-Rayからトレースデータを取り出してくる料金がかかります。 料金の見積もりは監視ダッシュボードの使用頻度によるため見積もりは難しいですが、弊社でAWSコンソールのCostExplorerから実際にかかっている料金を確認したところ、CloudWatchにかかっている料金の1/10程度となっていました。
引用元：Amazon X-Ray の料金
Amazon Managed Grafana
Amazon Managed Grafanaの料金体系は月額利用ユーザ数課金で、利用10名想定で$60/Month程度の試算です (監視対象サービス毎の金額ではなく、弊社内でトータルの金額)
以下参考で、自前でEC2インスタンスでGrafanaを建てた場合の検討ですが、弊社ではコスト比較で自前でGrafanaを建てるメリットはあまりみあたらず、まだ人数も少ないこともあり、まずは Amazon Managed Grafana で軽くはじめるで良さそうです。
- 自前Grafana
| 項目 | 料金 | 備考 |
|---|---|---|
| 構築(initial cost) | 人件費(2w) | Route53, ALB, SSO, AWSマルチアカウントテンプレート作成 |
| 運用(monthly cost) | $100/M | 以下合計 |
| vcpu(fargate) | ($73) | 2vcpu (2 * 30d * 24h * $0.051/h) |
| memory(fargate) | ($9) | 2G (2 * 30d * 24h * $0.006/h) |
| システムアップデート | 人件費 | Grafanaアップデート |
- Amazon Managed Grafana
| 項目 | 料金 | 備考 |
|---|---|---|
| 構築(initial cost) | 人件費(0.5d) | AWSコンソールからぽちぽちやるだけ |
| 運用(monthly cost) | $62-$120/M | 月額利用ユーザ課金: $9.00 (Editor license) $5.00 (Viewer license) 10名(Engineer(Server)+Manager): 3 * $9.00 (Editor license) + 7 * $5.00 (Viewer license) 20名(Engineer(All)+Manager): 4 * $9.00 (Editor license) + 16 * $5.00 (Viewer license) |
参考記事
Amazon Managed Grafana pricing
構築した監視ダッシュボードのご紹介
監視ダッシュボードへのログイン
まずは、Grafanaへのログインからですが、弊社では AWS へのログインは AWS SSO を利用しており、Amazon Managed Grafanaのユーザ管理画面でログインさせたいAWSユーザを追加すると、以下のように参加させたユーザからGrafanaのエントリーポイントのアプリケーションが見えるようになります。ここからGrafanaにログインします。
監視ダッシュボードの構成
パネルを以下の種類ごとにグルーピングして監視ダッシュボードを作成しました。
- プロダクトサービスを運用する上で最低限これだけは見る項目
- コンテナ詳細
- アプリケーションモニタリング項目
- データベース詳細
「最低限これだけは見る項目」は、監視ダッシュボードでは最上段に配置しました。
プロダクトサービスを運用する上で最低限これだけは見る項目
一番大事で最低でも見ておかなければいけないのはリクエストエラーレート、リクエストレスポンス(リクエストレイテンシ)の二つです。 BatchJobが存在する場合は、これにくわえて、Batchのエラーが発生しているかとBatch処理時間の最大値(時間的に許容最大値があれば超えていないかどうか)、 また、そもそもリクエストがきているか、リクエストのスパイクがないか、時系列のリクエスト推移に変化がないか、も見ておきます。
AWSでX-Rayを導入している場合、X-Ray Insightsという自動的に障害を検知してレポートをあげてくれる機能があり、これをそのままパネルとして表示するようにしました。StateがActiveであればまさに「障害中」なので、ここも必ず見ます(incidentの発生期間もレポートとしてよしなにまとめてくれるようです)
監視ダッシュボードを見るタイミング
- 障害発生時(言わずもがな)
- 本番リリース後、数時間程度経過観察
- 基本的に本番運用している場合は障害早期検知、未然検知という観点でも朝会で毎日1分でも見る
サーバチームの朝会で毎朝1分眺める、週ごとに監視担当を決めて回していく、等やりかたはいろいろなので、プロダクトチームのスタイルにあわせて監視体制を構築することになると思います。 継続的に見ることで、日々の変化から、障害の早期検知に繋がりやすく、最初はダッシュボードを見てもすぐに障害と気付けなくとも、運用していくとで練度があがっていき、熟練の目が養われた状態になるとダッシュボードをパット見たら怪しいところが分かる状態になれます。
その他見るべきポイント
障害の原因は、単純なバグの他、リクエストの高負荷、DBの高負荷、接続外部システムのダウン、Zone障害(センターの災害、センターで掃除のおばちゃんがサーバラックの電源足にひっかけて引っこ抜いた)等さまざまです。
リクエストエラーレート、リクエストレイテンシで異常がみられる場合は、X-Rayでエラーリクエスト一覧と、スローリクエスト一覧を見て、個別のリクエストのトレースを行って原因を究明を開始します。 外部システムがダウンしている障害も非常におこりやすいく、これもX-Rayのサービスのノードマップでどのサービスがダウンしているか特定します。
経年の変化はCPU/Disk/MemoryやDBのConnection数等を通して徐々にあらわれてきます。 システムダウンにつながる障害がおこりやすいのは、一番処理に時間がかかるDBで、DBの状態は特に把握しておく必要があります。 スパイクアクセスがあった場合、一番処理に時間のかかるDBに処理が集中し、DBのconnection数がはねがあってconnection上限に達してconnectionがつなげられなくなり、システムダウンに至ります。 システムダウンに至らなくとも、システム全体としてリクエストレイテンシが大幅に悪化し、ユーザ影響を与えます。事前に変化や負荷状態に気付ければ、DBレプリカやスケールの検討が可能です。
リクエストの高負荷はサーバの問題というよりリクエスト側の問題である可能性もあり、Frontチームに連携して不要なアクセスを省けるようであれば全体としてパフォーマンスがあがりユーザビリティの向上につながります。 サーバにリクエストがこなくなった場合は、Front側での何かのリリースエラーや、前段のロードバランサーのSSL証明書の期限切れ等が考えられます。 Zone障害はたまに発生する現象で、AWSでのベストプラクティスでは複数のavailability zoneに各々1台サーバを配置して、「センターで掃除のおばちゃんがサーバラックの電源引っこ抜いた」状態でも継続してサービス提供が出来るように構成を組んでおけるようになっているので、Zone障害でサービスダウンになっていればシステム構成をAWSのベストプラクティスに沿うように修正する必要があります。
さらに監視に対する知見を深めるには
毎日のサービス監視にくわえ、こちらの書籍などを読むことであわせてさらに深く知見をたかめていくことをチームメンバーにお勧めしております。
入門 監視 ―モダンなモニタリングのためのデザインパターン
SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム
他のサービスへの監視ダッシュボード展開の拡張性
今回作成した監視ダッシュボードは監視基盤設計で記載した弊社で現在サービスと使用しているAWSサービスの一通りのメトリクスを網羅しています。 作成した監視ダッシュボードはデータソース部分を変数化していて、新たなサービス追加時は、Grafanaのデータソース追加の画面からサービスを提供するAWSアカウントのデータソースを追加し、変数となっているデータソースを追加したデータソースに選びなおし、続いて変数化しているLoadBalancer、システム名(Project)を選びなおせば、新しいサービスの監視ダッシュボードが開始可能になっています。
最低限の監視ダッシュボードは秒で出来てしまいます(言い過ぎました...分だと思います...)。 あとは、必要に応じて、ダッシュボードにサービス固有のメトリクスを追加、必要ないメトリクスを削除していきます。
終わりに
ACES Meetのプロダクトの正式リリースのタイミングで、エラーレート、レイテンシの監視、アラーム通知の仕組みと、朝会で監視ダッシュボードを見る、というプロダクト運用を行うスタートラインに無事立つことが出来ました。
今後の課題
今回のフェーズでは、AIのモデルの品質の可視化や監視はスコープ外とし、まずはプロダクトのSRE的な監視基盤の構築をゴールとしました。 長い将来を考えるとプロダクトサービスはAIを包含して新しいステージ、新しい付加価値へさらに進化していくと予想されます。AIを含めて「顧客に価値を安全に素早く届ける」ために、
- AI部分を含めた安全を担保する網羅的なテストを、
- バランス良く形を保った高速なテストで品質を担保しつつ、
- 自動化されたテストにより、自動化されたデプロイメントに組み込む
必要があるのですが、現状AIのテストは手法が確立されておらず、優秀なアノテーターによりデータセントリックに学習データの品質を高めていくのが有効であり、Human in the loopで人間の目をはさんで定性評価して品質をモニタリングしていく必要があるという認識です。
弊社では、4月からはACES Meetでモデルの継続的学習パイプラインと、学習で出来たマルチモデルを素早く定性評価できる環境を構築していきます。 MLOpsとしてとてもやりがいのある仕事であり、今この瞬間今ここでしかできない仕事を一緒にチャレンジして頂けるメンバーを絶賛募集中です！
所感
昨年ACESにJoinして1年が立ちますが、ACES Meetを僅かのBizメンバーで必死に立ち上げているのを近くで見つつ、私自身も時にサーバAPI実装に入ったりでフルスタックエンジニアとしての仕事の醍醐味を感じつつ、プロダクトリリースにたどり着くところを目のあたりにして、0から1になるところに立ち会えて、これはそう何度も経験できるものではない貴重な経験だなというのを私自身もしみじみ感じながら仕事をすることが多かったです。素晴らしいデザイナー、素晴らしいフロントエンジニア、素晴らしく強いアルゴリズムエンジニア、尊敬出来る素晴らしい方たちと近くで仕事が出来たことに感謝。
そして、Happy monitoring!
ACESでは、積極的に採用を行っています。ACESに興味をもっていただいた方がいらっしゃいましたら、お気軽にご連絡下さい！
ACESのリクルートページはこちら↓
