はじめに
はじめまして。今年3月にウェルスナビのシステム基盤チームに新しくジョインしたSREの森と申します。今回がジョイン後初めてのテックブログ執筆となります。
序論
2024年8月3日(土)~8/4(日)にSRE NEXT 2024 IN TOKYOが開催されました。
弊社ウェルスナビもSRE NEXT 2024にスポンサードしており、スポンサー枠としてオフライン開催場所のAbema Towers[1]へ参加してきました。
シルバースポンサーとしてロゴが紹介された
1日目、2日目とフルで参加しましたので現地の様子を紹介いたします。
SRE NEXTについて
先にSRE NEXTの概要について説明いたします。
信頼性に関するプラクティスに深い関心を持つエンジニアのためのカンファレンスです。 同じくコミュニティベースのSRE勉強会である「SRE Lounge」のメンバーが中心となり運営・開催されます。 SRE NEXT 2024のテーマは「Beyond NEXT」です。SRE NEXT 2023で掲げた価値観 Diversity、Interactivity、Empathyを大切にしつつ、SREの担う幅広い技術領域のトピックや組織、人材育成に対してディスカッションやコミュニケーションを通じて、新たな知見や発見を得られる場にします。[2]
SRE NEXTはどこかの企業主催によるカンファレンスではなく、有志で募ったエンジニアらの運営によるコミュニティカンファレンスです。2020年から開催され、2021年を除いて毎年開催されています。
基調講演や公募、スポンサーからのLTセッションなども数多く提供され、会場ではスポンサー出展された企業や参加者同士の交流も活発に行われます。1日目は閉会式の後、懇親会も開催されました。
基調講演
Reliable Systems through Platform Engineering
開会式後、最初のセッションは基調講演としてGoogle Cloudでアドボケイトを務め、SREエンタープライズロードマップ[3]の著者の一人であるSteve McGhee氏の「Reliable Systems through Platform Engineering」から始まりました。
発表の概要として、障害発生時でも存続できるシステムを作るためにSREとしてどのように取り組みがあるか紹介してくれました。
最初は少ない労力、コストで多くの信頼性を得られるが、上がるにつれてわずかな信頼性を上げるために多くの労力、コストが必要になります。アーキテクチャによって担保できる信頼性やコストも変わるので要件に応じてアーキテクチャの選定が大事ということです。[4]
信頼性と労力コストのバランスが逆転する
弊社でも信頼性の向上とコスト最適化に日々取り組んでいるため、共感できる部分が多かったです。
日本最大口座数を保有するSBI証券のAWSマイグレーションを支えたサービスとソリューション
1日目最後の講演はSBI証券によるAWSへマイグレーション移行についてのお話でした。
今年4月に事例として発表されており[5]、国内最大級の口座数[6]を誇るSBI証券のオンライン取引システムをAWSクラウドへどのように移行したのか、同じ金融サービス企業として非常に気になっていました。
主題としてはオンプレミスからクラウドへ移行する際に事前の障害対策をどのように検証したかについて2つのAWSソリューションを活用してミッションクリティカルなシステム移行を成功したことについて述べていました。
負荷テストを実施する場合、負荷をかけるべき箇所や逆に負荷をかけてはいけない箇所などさまざまな要素を考慮しなければなりませんが、AWSが提供するDistributed Load TestingはCloudFormationのテンプレートが配布されており、デプロイして15分程で起動しテストの準備を短縮してくれたそうです。またApache JMeter[7]にも対応しており、普段利用しているJMeterのスクリプトをそのままアップロードできるなど今までの運用から大きな変更なくテストできたことも嬉しいポイントみたいです。
もう1つのソリューションがAWS Fault Injection Simulators Service(FIS)と呼ばれるフォールトインジェクションを実行するマネージドサービスです。
フォールトインジェクションとはシステムに意図的に異常を引き起こしてどのようなふるまいをみせるか確認するテスト手法[8]の1つです。
SBI証券では新規サービス公開前に実施しているみたいで、AZ障害を意図的に発生させてシステムがどのような反応をみせるか検証するそうです。
弊社も現在新規プロダクトを開発している最中ですので非常に学びのある講演でした。
セッション
SLO を満たせなくなったら
弊社でもSLOは導入しておりますが、SLOを満たせなくなったケースについてイメージできていなかったのでこのセッションには興味がありました。
セッションではSLOを満たせなくなったときはインシデントが発生しているときと捉えており、インシデント発生時の対応について発表されてました。
障害復旧する場合、完全な復旧を目指すのではなく多少の信頼性や可用性を犠牲にしてでもシステムを最低限利用できるようにすることでビジネスインパクトを小さくすることが求められます。
ただし、障害が発生すると焦りや不安から複雑なオペレーションはできなくなるので、事前にどのような復旧対応するか決めることが大事です。
弊社でも障害が発生した場合インシデントを知らせる通知が、一次障害対応が記載された手順書と共に関係者に共有されます。
障害対応後はポストモーテム[10]と呼ばれる障害報告書を記載しますが、セッションでもポストモーテムの書き方について述べており、人を責めないことが大前提と話されてました。
なぜなら、ポストモーテム内で特定の人に原因があるかのように書いてしまうと心理的安全性が下がってしまい、失敗を恐れて挑戦をしないチームが出てきてしまうようになるからです。
またインシデントが発生した時のリスクが何なのかを把握するためにリスク分析をする企業も多いと思います。
Googleではリスク分析する時に用いる指標として以下の三点を活用していると述べられてました。
- ETTD(Estimated Time To Detection)
- 障害が発生してから人が認知するまでの時間
- ETTR(Estimated Time To Resolution)
- 障害を認知してから復旧するまでの時間
- ETBT(Estimated Time between Failure)
- 次の障害が発生するまでの時間
この指標にユーザーへの影響度を加えた4つの項目を評価したリスク分析を行ないます。
参考資料として紹介されたGoogleブログでは指標を基にした図も提示されていますのでこちらもご参考になれば幸いです。
ブログより引用
今のチームで実践できてる部分がありつつ、リスク分析手法など学べる分野も多いセッションでした。
徹底的な自動化とトイルの撲滅で実現する効率的なSREの実践例
私が所属するSREチームは「事業拡大を見据えた10倍規模の運用(社内では10X運用と呼んでます)を可能にするためのプラットフォームを構築する」という目標を掲げており、それを実現するためには標準化や自動化は必要不可欠だと考えています。
弊社でもTerraformを使ってAWSやDatadogのリソースをコード管理しているため、視聴前から気になっていたセッションでした。
モジュールとしてコードを再利用できるにしているのは弊社でも同様ですが、MIXIのSREチームは少人数でも運用できるように内製のTerraformコード自動生成ツールを活用、モノレポによるCI/CD運用といった徹底した自動化で人の作業を減らす取り組みをされてました。
ただGitHub Actions上でTerraformのCI/CDパイプラインを実装するとCIの実行時間が増えてしまうデメリットがあります。
セッション内ではジョブのマトリックス戦略[11]で並列にジョブを実行することで時間を短縮していると話されてました。
気になったのは並列実行してもコンピューティングリソースの消費量が増加することに変わりないためコストが増えてしまうことでしたが、この点について質問したところコストとして割り切っているとのことでした。
私も前職でTerraformのCI/CDパイプラインを実装する際に実行時間が長くなってしまう問題がありましたのでジョブマトリックスで並列処理するのは学びになりました。
会場の様子
今回の会場では2フロアを使ってのイベントとなり上層ではスポンサー企業のブースコーナーや参加者同士の交流スペース、下層では先ほどの基調講演や公募/スポンサーセッションが複数ルームで開催される仕組みになってました。
各社ブースではアメニティーグッズの配布やSRE NEXTのロゴ入りトートバッグなど数多くの品物を頂けました。どのブースの前にも参加者が多く集まりアンケート回答や技術討論で多くの盛り上がりをみせてくれました。
私がワクワクする領域は自動化効率化です
採用で苦労されている人も多いみたいですね
私はToil削減が好きですが皆さんはいかがでしょうか
弊社ではBitbucket Pipelineを使っていますがあまり他社では使われてないようです
懇親会
1日目の閉会式が終了した後会場の近くのクラブで懇親会が開催されました。
たいていカンファレンスの懇親会といえばイベント会場内で行われることが多かったですがクラブを貸し切っての懇親会は初めてで100人以上の参加者がクラブ内に集まり大盛り上がりとなりました。
私も何人かの参加者と交流して技術交流や弊社主催のエンジニアイベントを紹介して懇親会も楽しめました。
まとめ
2日間にわたって開催されたSRE NEXTの体験レポートを書かせていただきました。昨年から参加していますが、これほど多くのSREが集まるカンファレンスイベントはなかなかないと思います。
弊社のエンジニア組織は急速に拡大しており、SREチームもこの半年間で規模が倍増しました。このような成長期において、他社様の知見を取り入れることは非常に重要です。今回のイベントを通じて、他社の成功事例や課題に触れ、会社に貢献できるスキルを身につけるための良い機会となりました。
📣ウェルスナビでは一緒に働く仲間を募集しています📣
プロフィール
森 祐太朗
システム基盤グループ システム基盤チーム所属
新卒の会社で金融機関のシステム運用を経験。その後複数の転職を経てウェルスナビ株式会社にSREとして入社。現在は資産運用サービスや新規プロダクトのインフラ環境構築を中心にサービス運用改善、監視運用、IaC開発などを担当しています。
-
https://www.cyberagent.co.jp/corporate/access/abematowers/ ↩︎
-
公式ページより(https://sre-next.dev/2024/) ↩︎
-
https://sre.google/intl/ja_jp/resources/practices-and-processes/enterprise-roadmap-to-sre/ ↩︎
-
アーキテクチャの選定についてはこちらのドキュメントも参考になります。(https://cloud.google.com/architecture/deployment-archetypes?hl=ja#zonal) ↩︎
-
https://aws.amazon.com/jp/about-aws/whats-new/2024/04/sbi-securities-completes-migration-online-trading-systems-to-aws/ ↩︎
-
https://microsoft.github.io/code-with-engineering-playbook/automated-testing/fault-injection-testing/ ↩︎
-
https://www.atlassian.com/ja/incident-management/incident-response/how-to-create-an-incident-response-playbook#incident-response-lifecycle ↩︎
-
https://docs.github.com/ja/actions/writing-workflows/choosing-what-your-workflow-does/using-a-matrix-for-your-jobs ↩︎
Discussion