この記事は Nikkei Advent Calendarの12日目の記事です。
はじめに
SRE(Site Realiability Engineering)チームの杉本です。弊社では日経電子版をメインとするBtoC向けサービス開発に加えて、BtoB向けのサービス開発を行う部署もあります。SREチームはこれらの部署に横断的に関わる唯一のチームとして、各チームとの連携や採用技術の取りまとめと共有、サービスの新規構築やリプレースに際してのインフラ周りの設計レビューなど、日々色々なメンバーとコミュニケーションを行いながら主に運用面のサポートを行っています。
取り組みは多岐に渡るのですが、その中で本エントリでは代表的な3つの取り組みをご紹介致します。
日経のSREの取り組み3つ
各チームとの連携、運用サポートと個別ポストモーテム
1つ目から「そんなの当たり前でしょう」と言われることかもしれませんが、今までこれができていませんでした。 冒頭に唯一の横断チーム、と書きましたが、今までチーム間のコミュニケーションがあまり取られておらず、採用技術や解決策などがプロジェクト内に留まってしまっている現状があり、各チームには特定の分野に詳しいメンバーもいて知見も沢山あるのに共有されていない、という勿体ない状態でした。そこでSREがハブとなり、技術や知見を他チームにも展開し、困りごとにはその分野に詳しいメンバーを別途呼んだりなど、各チームの困りごとを部署全体で解決するような取り組みを行っています。各チームとの連携会議では、
- アイスブレイク（雑談タイムが多いです）
- SREで開発している可視化ツール/Kibanaからエラー傾向やレイテンシなど、週次で特徴的な部分を見ながら解決策・改善策を議論する
- 障害についての個別のポストモーテム実施
- 採用技術や実装面について、他チームの状況を共有または吸い上げ
といったことを主に話し合っています。週の最初にSREチームでプランニングを行い、他チームの状況をまとめてどういう情報を共有するか、などを話し合うことで、チームごとに必要な情報を提供できるようにしています。また2を最終的にSLI/SLO策定の指標として数値化していく狙いもあります。
話す内容も大事ですが、まずはコミュニケーションが大事なので、ざっくりと話しつつ時々議論を深めることに重きをおいています。 日頃は機能開発に忙しいチームメンバーもこの時間はチームでやってきたことを振り返る時間にしてもらったり、それぞれのプロジェクトの現状を知る、という意味でもSREチームに取っては有用な時間になっています。
障害管理
現在の障害時の運用として、Slackの障害報告用チャンネルに障害の報告が上がると関係者が集まり、オンライン会議で議論、解消後に報告、という一連の運用フローが構築されています。
しかしながら、対応された障害についての振り返りが行われていなかったり、再発防止のためのアクションがきちんと最後まで実行されているかが追えないなど、事後対応が不足している部分がありました。障害対応中に報告書を起票するのはすごく大変ですし、私も対応中はそんな余裕はありません…ので、SREがこのあたりの起票の取りまとめとポストモーテムの実施のハンドリングまでを実行する計画を立てています。
また、起票をSlackベースで自動化、障害の履歴をDB化、ネクストアクションの実行の確認などを管理するIRMツールも自作しています。これはGoogle社のIRMが途中で無くなったり、Netflix/dispatch がちょっと微妙だったりでIRMに適したツールが見つからなかったため、我々のワークロードに合ったツールを開発することにしています（OSSにしたいという気持ちがある…と書いておくと実現するかもしれないので書いておきます）。
参考: 【いでよ障害対応太郎】我々はインシデントにどう向き合っているのか 〜社内向け障害対応リスト付き〜
また合わせて障害の深刻度を示すSeverity Levelの策定をBCPの観点からも検討を始めています。
日経電子版Web向け新アプリケーション基盤の開発
最後に突然技術寄りの話題になりますが、現在では一番大きな取り組みと言えるので紹介します。
現行の日経電子版Web（以下、日経電子版）はいくつかインフラの変遷を辿ってきています。
以前に日経電子版を支える広告技術 というエントリを書きましたが、丁度この頃はAWS Elastic Beanstalkを使ったマイクロサービス構成であり、その後GKE基盤に移行しました。詳細は以下のスライドを御覧ください。
GKE+Istio+GitOpsで作る日経電子版の次世代マイクロサービス基盤
その後、GKEのシングルクラスタ運用においてはクラスタのアップデートが難しく、いわゆる塩漬けになってしまう問題が出てきました。Kubernetesを運用している方はみなさんがこの問題に立ち向かっているのではないでしょうか…。特に弊社においては日経電子版がダウンすることによる影響は大きいと考えており、安全にクラスタを更新するべく本節の新アプリケーション基盤の開発に着手しました。
既存のGKEシングルクラスタ構成
マルチクラスタ構成を実現するために沢山の技術検証を行いましたが、最終的にGoogle社のAnthosを採用しました。本エントリでは詳細な技術については省きますが、更新先クラスタを同一構成で作成し、リクエストを新クラスタに流しつつ、旧環境をシャットダウンする一連の更新をダウンタイム無しで行えるようにします。またAnthosを使うことで別リージョンに対しても同じようにクラスタを展開することが可能となり、リージョン耐障害性も上がりました。
新基盤:マルチリージョン構成の例
AnthosはロードマップとしてAWSやAzure、On-Premisesでの運用も見据えているのでゆくゆくはマルチクラウドでの運用に持っていければな、と考えていますが、GCP/AWS間リソース（CacheやDatabase）との接続をどうしていくか、などまだまだ検討するべき点は残っています。
また本基盤に対して負荷試験を実施するために負荷試験基盤を作って展開する、といった副次的なプロジェクトも生まれました（これは9日目のエントリで書かれています）。
最後に
簡単ではありますが、日経のSREの取り組みについて紹介しました。
日経のSREチームは発足してまだ2年弱程です。SREの取り組みとしてよく語られるのはGoogle社の Site Realiability Engineering ですね。私も一通り読みましたし、他社さんのSREチームの取り組みについてのエントリを見つけては拝読していましたが、比較するとまだまだ取り組んで行かないといけないことが沢山あります。
冒頭では多様な取り組みがあると触れましたが、SREチームではメンバー全員が全てを担当しているわけではもちろん無く、基盤開発、ツール開発、コミュニケーションなど、それぞれが得意分野に集中することで、日経電子版を含めた日経の各種サービスの安定稼働・運用改善に携わっています。
SREの経験のある方はもちろん、これからSREを始めていくことに興味のある方も、ぜひお気軽にご連絡ください。
