「カミナシ レポート」の開発・運用をしている furuya です。今日は「サービスの健康診断」のお話です。
週次の健康状態チェック：運用定例
「カミナシ レポート」の開発チームでは週に1度、運用定例というものを開催しています。以前のブログ記事 より以下抜粋します。
また、そのダッシュボードを毎週見る会を始めました。一緒に運用にまつわるあれこれをまとめて確認する会ということで、運用定例（Service Review）と呼んでいます。ここでは他にインフラコストの確認やAWSなど利用する外部サービスからの通知の確認、障害・ヒヤリハットの周知などを行っています。
Datadog 上に構築したダッシュボードを1週間スパンで眺め、メトリクスが跳ねているところがないか、徐々に遅くなっているエンドポイントはないか、といった観点でチェックを行います。アラートにまでは派生しなかったものの異常値が見られたり、詳細な調査が必要になった場合は対応チケットを切り次スプリントにて調査を行います。
年に1回の人間ドック
今回はこちらのお話がメインです。週次スパンだと長期のトレンドや、今後どうなっていきそうなのか、といったところが見えないため年単位で見ていく機会を設けました。
目的
- インフラメトリクスの現状を見て、これからの予測を考えてみる
- 今のインフラの状態を理解し、このままほっとくと1年後にはどうなっているのか、のイメージをチーム内で揃える
- 転じて直近立ちはだかりそうな壁を知る
大きく以下3つの観点で見ていきます。
観点1. パフォーマンス
まずは Datadog ダッシュボードを1年スパンにして眺めてみます。普段は週次、長くても月次スパンでしか見ないので長期間の傾向を確認します。
たとえばこれはとあるエンドポイントのレイテンシのグラフですが、これを見ながら「この時期はxxxでちょっと悪化していた」「とある施策によりパフォーマンスがあがった」など1年を振り返りつつ、「今後の傾向はどうなりそうか？」「徐々に遅くなっている傾向があるので注視が必要」など未来へ向けての認識を揃えました。
観点2. キャパシティ
こちらもメトリクスを1年スパンで眺めます。対象は主にコンピューティングリソースで「カミナシ レポート」はクラウドインフラストラクチャとして AWS 、コンピューティングは ECS（Fargate）、データベースは Aurora を利用しています。これらの CPU、メモリを見ていきます。
ここでも現状と1年間の傾向を見つつ「まだ余裕がありそうだから折を見てリソースを調整してみよう」「直近しばらくはインスタンスサイズを変えなくても大丈夫そう」といった認識合わせをしました。近く Reserved Instance や Savings Plans の購入を控えているので、変更があれば対処できるくらいの余裕をもって今回の人間ドックを実施しているのもミソです。
予測のために使った機能として、Datadog の Forecast があります。以下は単純な例（Aurora のストレージ利用量）ですが、ここからストレージ使用量を予測してそれによる利用料金を具体的な数値として算出できます。
観点3. コスト
みんなだいすきコストも見ていきます。ここでは特に、全体からみて割合が高いものや変動率が高いものに着目し、1年前と比べて / ビジネス指標的に今の金額は妥当かどうか確認します。
コスト削減の施策効果についても確認しました。直近でいうと、S3 の特定のバケット/オブジェクトに対して Glacier Instant Rerieval（年に数回しかアクセスしないが、必要なときには通常の S3 オブジェクトと同等の速度で取り出せる、長期保存向け低コストストレージクラス） への変更の設定を入れたのでその効果を見つつ、変更までの期間をチューニングするか否かの議論を行いました。ストレージタイプの変更自体にもコストがかかるためトータルの削減額としては大きくありませんでしたが、現時点のコストを少しでも下げつつ今後のコストの伸びを抑えるという意味では複利で効いてくる施策です。もともと変更の決定を行ったときは、ストレージクラスの変更にかかる総コストは2, 3ヶ月でペイできるという試算で始めたのですが、思ったよりも古いオブジェクトへのアクセスがあったためペイできるまでの期間が多少伸びそうです。コスト削減自体はできているので変更期間はそのままにして、また半年後くらいに効果を測定しようと考えています。
ポイント
今回の人間ドックで得られたことは2つあります。
1つめは、幸いなことに今回の人間ドックでは直近1年でぶつかりそうな大きなインフラ課題は見つからなかったことです。たとえばキャパシティ面だと DB のストレージが1年以内に枯渇するかもしれない、といったことがわかった場合は早めに対処することが必要です。そのため少なくとも「1年後どうなっていそうか？」という観点で過去の傾向から未来を予測することがダイジだと思っています。
2つめは、去年1年間のうち様々な場面で実装した施策が効いておりパフォーマンスが全体として1年前より改善していることがわかったことです。個々の施策による確認は週次の運用定例で確認していますが、やはり1年というスパンでみたときに「以前よりよくなっている」という実感を得られることは開発チームのモチベーションになります。
まとめ
自分たちが運用しているサービスの健康を保つためには普段のモニタリングに加えて、長期の目線で振り返りとこれから襲ってくるであろう事態に備える必要があります。我々人間の病気もそうですが、早期発見が大事です。人もサービスも定期的な健康診断をしていきましょう！
カミナシでは開発はもちろん、このような活動を通してサービスに向き合いたいエンジニアの方を募集しています！また、宣伝になりますが1/28（水）に AWS re:Invent の re:Cap を開催します！豪華ゲストに登壇いただいたり、現地参加メンバーならではのトピックが聞けたりしますので是非ご参加ください。
