本記事は
ブログ書き初めウィーク
2日目の記事です。
📝
1日目
▶▶ 本記事 ▶▶
3日目
📅
こんにちは、NTシステム事業二部 基盤課 の玉邑です。
2024年7月にNRIネットコムに入社し、AWS上に構築された大規模システムのインフラチームリーダーを担当しています。お客様のビジネスの変化に迅速に対応するため、DevOpsで開発を行いながら、安定稼働を支えるSREを担当しています。
15年以上にわたりインフラエンジニアやクラウドアーキテクトとしてキャリアを積んできましたが、現在担当しているシステムはこれまでで最も規模が大きいものです。今回の記事では、入社してからどのようにしてその大規模システムを理解し、リーダーとして業務をキャッチアップしていったかについてお話ししたいと思います。
担当したシステムについて
私が担当したシステムは、先人が培ってきたノウハウを活かし、AWS Well-Architected Framework*1が実践されているシステムでした。
- 高い信頼性を実現するクライアントと連動した再試行可能なアーキテクチャ
- 様々な負荷に対応した柔軟な拡張性とコスト最適化
- システムの異常に迅速に応答するための運用体制
- 予防的・発見的統制によるセキュリティ対策
そのようなシステムを担当するにあたって、まずは概要の引き継ぎを受けたうえで、各種ドキュメントの確認を進めました。このシステムは要件、設計、運用実績などがしっかりとドキュメント化されており、それらを読み込むことで一つ一つの仕様を理解することができそうでした。
ただ、システムの規模や歴史と相まって、文書量が非常に多く、私の記憶装置は途中で悲鳴をあげていました。
そんな折、前任者の計らいで、まずは監視の改善テーマに取り組むことになりました。
このWell-Architectedなシステムも、長年の継続的な改修を経て、様々な改善のポイントがあり、その一つのテーマとして監視の改善があったのです。
結果的に、この監視の改善タスクを最初に担当したことで、システムのことを広く深く知ることができました。 ここからは、監視改善を通してどのようにシステムを理解することができたのかをご紹介します。
監視を通じて知る大規模システム
システムの全体像を知ることができる
多くのシステムでは監視には、様々な実装方式で各監視が設定されていると思います。
死活監視・リソース監視・プロセス監視・ログ監視・ネットワーク監視・イベント監視・外形監視・高度なアプリケーション性能監視 (APM)・セキュリティ監視・コスト監視 など、実装方式が多岐にわたる監視の内容をひとつずつ紐解いていくと、色々なシステムの特徴が見えてきます。
例えば、
- 死活監視やプロセス監視でサービス提供にあたって必要になるコンポーネントやサービスは何かを把握できます。
- リソース監視で性能のボトルネックになりうるリソースのポイントを知ることができます。
- 外形監視で具体的にどのエンドポイントが、ユーザーの体験に直接的に影響を与えるかを理解することもできます。
- コスト監視などでそのシステムが主にどのようなサービスがコストのポイントになっていて、開発業務などで予期せぬコスト増を防ぐために注意が必要か知ることもできます。
このように監視の実装内容を確認し、どのようにモニタリングやアラーティングを設定しているかを把握することは、システムの全体像を理解するのにとても役立つと思います。
システムの重要なポイント（要所）が見えてくる
大規模システムになると、すべての問題に対して、迅速に解決に取り組む消防士のような活動だけでは必ず対応の限界がきてしまいます。 統計データを分析して、対応を自動化したり、アーキテクチャを見直したりするポイントを特定することもSREとしては重要な役割のひとつです。
その監視の改善のポイントとして、どのリソースに注目すべきか？を考えるためには監視のダッシュボードを通して、 システムの統計データを確認して分析していくことになります。
- どのようなサービスが普段活発に動いているか
- ピーク時間帯や期間はあるのか
- それらの問題にどのようにスケールしながら対応しているか
- 過去の障害での動きがどのように異なるのか
というシステムの実際の動きを観察していくことで、システムの重要なポイント（要所）を知ることができます。
日々変化する状況において、これらのポイントは設計書の中では表現しにくい部分だと思います。 パフォーマンス設計などから推察していくこともできますが、実際のデータを見るというのが最も手っ取り早い方法だと思います。
監視の意図を深掘りしてシステムの特徴を知る
一般的な監視設定と異なる箇所などがあれば、その設定の意図などを深掘りすることでシステムの特徴を発見するきっかけになります。
例えば、このシステムでは特定の外部接続システムとのトラフィックの急激な減少を監視していました。
一般的にリソースは上限を閾値に設定して監視することが多いので、なぜ減少することを監視しているのか、その意図を設計書や障害記録で確認すると、
「外部接続システム側での障害でトラフィックが減少すると、その後、外部接続システムの復旧に伴って大量アクセスのスパイク負荷が発生することが過去の事例であったため」
ということがわかりました。
このシステムでは外部接続システムからの急激な負荷増に備える準備が行われていることを、監視を通して確認できました。
このように、安定稼働にインパクトを与える場合には何らかの監視が障害事例などで追加設定されているケースもあるので、気になる監視設定は深掘りしてみることで、そのシステムならではの特徴を理解することに繋がります。
利用しているAWSサービスの特性がわかる
最後に、少し変わったところでいうと、システムが稼働するAWSサービスなどの特性を垣間見ることもできます。
この監視改善の活動の中のテーマのひとつにCPUアラートの頻発がありました。 Amazon ECS のCPU使用率によるAuto Scalingを設定しており、アラート閾値はオートスケール閾値より高く設定しているにも関わらず、 AWS Fargateの一部でCPUアラートが発生していました。
負荷は均等に分散され、急激な負荷の増加がない中で、なぜ一部のFargateだけでCPUアラートが発生しているか原因を確認していくと、 Fargateが稼働する環境で想像していたよりも、性能にばらつきがあることがみえてきました。
Fargate上からCPU情報を確認してみたところ、使用されているCPUは様々な種類のものが採用されていることがわかりました。
このようにFargateで割り当てられる性能は制御できないため、性能のばらつきを前提とした設計を行う必要がありました。
この事例では監視の見直しだけでなく、その性能特性を理解した上で、Auto Scalingの設計を改善する余地があることを把握できた点も収穫でした。
まとめ
監視の改善というような内容は、日々の開発に追われているとどうしても優先度の上がらないテーマだと思います。 しかしながら、監視の改善はアラートに対応するメンバーの負荷を直接的に下げることにつながりますので、目に見える形での改善効果も生まれやすいと思います。
ぜひ新しいメンバーにも参画してもらいながら、チーム全体のシステム理解を深める方法として監視改善に取り組んでみてはいかがでしょうか。
*1:AWS Well-Architected Frameworkは、クラウド上でワークロードを設計および実行するための主要な概念、設計原則、アーキテクチャのベストプラクティスを提供するためのフレームワークです。
