この記事はNikkei Advent Calendar 2021の23日目の記事です。

はじめに

SREチームの杉本です。昨年のアドベントカレンダーでは 日経におけるSREとその取り組み というエントリでSREの取り組みについてご紹介しました。

その後も取り組みについて試行錯誤を繰り返し、ようやく日経のSREはこんな風にやっています、という形ができてきました。 本エントリではアップデートとして2021年のSREの取り組みを振り返りつつ、今後の取り組みについてもご紹介できればと思います。

SREチームのプロジェクトに対するエンゲージメント

SREチームのプロジェクトへのエンゲージメント手法は色々ありますが、弊社では日経電子版だけでなく、認証基盤、課金基盤、法人向けサービスなど、数え切れないほど多くのプロジェクトが開発・運用されています。一般的には、各サービスにバンドルされているSREチーム、すなわちEmbedded SREsとして活動されているケースが多いと思います。

実際に他社様の事例をお聞きする中で、関わるプロダクトのOps周りの整備やSLI/SLOの策定など、その取り組みについて非常に学ぶものが多かったのですが、翻って日経で考えると、上記のような多くのプロジェクトにEmbeddedするためにリソース不足なのは明らかでした。そこでCore SRE / Team SREの考え方でエンゲージメントを上げていくことにしました。

Core SRE / Team SRE

SREチームはCore SREの役割を担っています。Core SREとはSREに関する活動方針をブレインとして検討する部分で、部署全体を俯瞰しつつインフラや監視を共通化するための施策を検討したり、どのチームも使えるツールの開発と提供を行ったりしています。一方のTeam SREは、小さなEmbedded SREsの役割として、Core SREの方針を踏まえつつ、議論しながら対象プロダクトの改善を実行します。

SREチームは組織上、横断チームという立ち位置であり、個別の裁量を持って動くことと、提供しているサービスの数に対するチームメンバーの数から考えればこのような方式になるのは自然なことでした。また、Team SREは実際にプロダクト開発をしているメンバーにその役目を担ってもらったり、Core SREのメンバーが一時的にEmbedしたりといった、Movable Embedded SREsの振る舞いを担ったりと、フレキシブルな運用としています。

本エントリではCore SREとして2021年に取り組んで来たことをご紹介します。

インフラスタックの共通化

日経ではインフラ構築の際にはAWSを採用するケースが多いですが、BCPの観点からも特定のクラウドにロックインせずに、GCP/AWSどちらでも稼働できるように選択肢を増やそうとしています。SREチームではこれらを共通化するための仕組みを提供しています。

Google Cloud Platform

昨年のエントリでは日経電子版Web向け新アプリケーション基盤として紹介したインフラ基盤ですが、2021年にはBFFアプリケーションの全てを新基盤に移行しました。この取り組みは Open Cloud Summit でメンバーが発表していますので参照ください。

Open Cloud Summit 2021 に登壇してきました

上記スライドで語られている通り、クラスタの安全なアップデート、BCP対策としてリージョン耐障害性が向上しました。またSREチームが基盤を運用監視することで、間接的にエンゲージメントを高められる図式にもなりました。今後はこの基盤を汎用化していくことをロードマップと定めています。

今までは日経電子版のみを考えれば良かったのですが、カテゴリの異なるアプリケーションを載せるとなると、Namespaceの区切りやDBやCacheといったリソースをどう管理するかなど、考えることは増えていくでしょう。SREチームでは実現する構成を日々検討しています。

Amazon Web Services

上述の基盤はGKEで構成されているため、AWSを選択したプロジェクトのために、ALB + ECS + CodeDeployのスタックを構築できるTerraform Moduleを開発して提供しています。SREチームがモジュールのメンテナンスを担うことで、アップデートへの追従や同一の方法でインフラ環境を構築できるようにしています。特に後者についてのメリットは大きく、インフラ構築の手法を一元化することによって、SREチームが導入プロジェクトの構成を把握しやすくなるなど、これまでそれぞれの方法で構築されていた現状を改善する足ががりになることを期待しています。

障害管理ツールの運用

昨年のエントリで、我々のワークロードに合ったツールを開発している、と言いましたが、「hawkeye」という名前でツールを開発し、運用が始まりました。 日経ではほぼ全てのメンバーがSlackを使っているので、招待不要でSlackのOAuthでログインできるようにしています。またマルチチャンネルユーザについても別途ログインを提供することで、開発に関わるメンバーは誰でもこのツールを閲覧することが可能であり、過去の障害を検索して対応策を調べたりすることが可能になりました。

現状の障害時のワークロードを簡単にするため、IRMツールでは以下のようなことを可能にしました:

• Slack/コンソールから障害報告が可能
  • 障害対応チャンネルを自動作成、プロジェクトメンバーを自動アサインし、Incident Response Templateに基づいて指揮者、コミュニケーション役、障害対応者を選出
  • 対応補助ツールとしてGoogle Meet / Google Docs（報告書） を自動作成
• 障害対応フローのDB化
  • 障害対応チャンネルへの投稿をSyncしてツール内に保存
  • Severity Level、障害ステータスの管理
• ポストモーテムマネジメント
  • 振り返りに必要な情報を記載して保存
  • 再発防止のアクションの決定とトラッキング（Slackへ通知）
• 障害サマリ
  • 障害件数とそれに対するポストモーテム実行数の可視化

全ての機能が使われているわけではありませんが、日頃の各プロジェクトとのコミュニケーションの成果もあり、各チームの障害情報がこのツールに記載されるようになりました。これにより、SREチームが障害状況を把握し、再発防止アクションの内容からSREとしてのアクションを検討したりすることが可能になりました。

デファクトのIRMツールはそれほど見つけられておらず、上記の機能はSlackを導入しているプロジェクトであれば汎用的に使えるかもしれません。細かいバグやリファクタリングの必要がありますが、今後OSSとして提供できれば、と考えています。

SLOプラットフォームの開発

SREの活動としてSLI/SLOはよく語られますが、サービスが稼働している状態、また どれくらい稼働しているか を定量的に評価するためにプラットフォームの開発を始めています。同時に日経のサービスにおいてSLOを下回ることによってどんな損失が生じるのか、といった点も改めて一から検討し直しています。

主観を排除したサービス稼働、またはサービスダウン

サービスが落ちている状態の定義は人によって異なります。例えば開発者がアクセスして問題がなくても、エンドユーザーにはエラーを返している可能性もありますし、その逆も然りです。あるタイミングで誰かがエラー画面に遭遇すれば、サービスダウンとして社内に共有されることもあるでしょう。

このような、 なんとなくいい感じに動いている状態 は不確かで、各人（ともすればプロダクトオーナーのような権威のある人）のコンテキストに依存します。。例えばSLIが99%だったとしても、その時にアクセスしてエラーに遭遇しなければ動いている状態として認識されることでしょう（実際に深刻なエラーが出ればアラートが飛ぶ仕組みになっているでしょう）。

マイクロサービス（ページ）毎のSLO

例えば、日経電子版では知事選の開票速報を表示したりしますが、こういったページは高負荷であると同時に高い稼働率を要求されます。 サービスを落とさないように という指令に対して、それはどれくらいのエラー率を許容するのかを数値ベース語りたい（100%が理想ではあるが不可能という前提で）という意図もあります。

また、あるサービスが別の社内APIに依存しており、そのAPIが別の基盤と接続しており…というサービスの組み合わせにより提供される機能もマイクロサービスではあるでしょう。これらの組み合わせにおいては依存先のSLOを上回ることはできないですが、その場合SLOは何%にすべきなのか、といった点も考慮したいと考えています。

こういった なんとなくいい感じに動いている状態 や 落ちてはいけないサービス は何%の稼働率なのかをSLOとして定めるために、サービスのログを収集し、実際のエラー率、レイテンシなどから稼働率を算出することで、サービスの状態から属人性を排除して定量評価していきたいとチームで検討を進めています。

プラットフォーム構成

各サービスのアクセスログを集約し、閲覧できる仕組みはありつつも、そこから実際に稼働率を計算し、SLOを決めるためのデータを取るためにはもうひと工夫が必要でした。

そこで、SRE Workbook のSLO Engineering Case Studies に習いつつ、日経に必要な情報を収集できるプラットフォームを構築し、ビジネスサイドとSLOを策定し、運用しながら定期的に点検するためのツールとして活用していく予定です。

まとめ

2020年の取り組み のアップデートとして2021年の日経のSREの取り組みをご紹介しました。 トライアンドエラーを繰り返す中で、社内でのSREの認知度の高まりもあって、ようやく日経のSREはこういうことをやっている、と紹介できるようになってきました。これは私達にとっては大きな進歩だと思っています。

まだまだ解決すべき問題もたくさんありますが、横断的にチームと関わりを持ちながら、技術面から各サービスの安定稼働に携わっていく取り組みはこれからも続いていきます。そのためには共に考えながら実行していくメンバーを増やしていきたいです。

本エントリでご紹介した取り組みに興味を持って頂けた方、もっと詳しく聞いてみたい方、カジュアル面談は随時行っていますので、JOBSをご覧の上、お気軽にお声がけ頂ければと思います。