はじめに
初めまして！6月よりメディアドゥにJoinしたサーバーサイドエンジニアの角田です。
みなさんAWSは使ってますか？
私はとある社内システムのクラウドリフト案件で絶賛活用中です。
さて、先日AWS社ソリューションアーキテクトの八木さん(@ygtxxxx)協力のもと、同社シニアソリューションアーキテクトの大村幸敬(@yktko)さんに表題の勉強会を開いていただきました。 昨今当社でも新しい部署として立ち上げられたSREの話題が中心ですが、開発サイドの方にも非常に有益な内容でしたので概要をレポートしたいと思います！
内容
アジェンダは下記の通りです。
各章の内容や所感についてまとめてみましたのでご覧ください！
※ ⑤参考文献 は割愛
①運用って何だ
このセクションでは、「そもそも運用とは何なのか」をブレイクダウンしてご説明いただきました。
ユーザー視点でシステム運用について分解していく考え方が個人的にもとても参考になりました！
システム運用はユーザーから事業者側に向かって考えていく
-
ユーザーがサービスを利用していて、困ることは大きく分けて以下の8つ。
- 繋がらない
- 遅い
- 不具合
- 問題が繰り返し起こる
- 誤課金
- 機能が追加されない
- 始まらない（サービスが）
- 終わる（サービスが）
-
これらの問題は大抵システムリリース当初は問題ないが、以下のような原因で顕在化してくる。
- 繋がらない ← サーバーダウン／サービスダウン／通信回線断
- 遅い ← 過負荷／容量不足／人手不足
- 不具合 ← ソフトウェアバグ／仕様バグ
- 問題が繰り返し起こる ← 再発防止策の未実施
- 誤課金 ← データバグ／システム連携不具合
- 機能が追加されない ← 継続的な開発／継続的なリリースがされない
- 始まらない（サービスが） ← 初期計画のミス
- 終わる（サービスが） ← ビジネス計画／コスト計画のミス
-
こうした諸問題に対応していくのが「運用」。マンパワーで対応するものと自動化／スケール等のテクノロジーで対応するものに切り分ける。
上記を踏まえてユーザーが困らない為には
- ユーザーが期待するサービスレベルを数値で定める。（SLI,SLO,SLA）
- 可用性の指標を定めて障害時の仕組みを設計する。（RTO,RPO,RLO）
- インシデントからの回復方法を設計する。
- 可用性やセキュリティばかりを追い求めてリリースのタイミングを遅らせては逆効果。事業に合わせた設計が重要である。
- バランスをとる為には、リスクをどれくらい許容するのかを数値として定め、リリース速度のハンドリングを行う。（エラーバジェット）
②運用について知っておいた方がいい事
本セクションは「運用について知っておいた方がいい事」について解説いただきました。
こうした知識はSREのロールを担う方はもちろんの事、僕のようなサーバーサイドエンジニアも知っておく事が重要なのだと感じました。
余談ですが「非機能要求グレード」はSI系の会社に在籍していた時に幾度も格闘した思い出があり、懐かしい気持ちになりました（笑）。
障害対応について
- 対応を行うのはもちろん、お客様に適宜コミュニケーションをとるのも重要。
- 障害報告書の代わりに「Postmortem」を用いるケースが増えている。
- 構成は障害報告書と同じだが、内部のLearningに重きを置く点が特徴。下記のような内容で書くケースが多い。
- やって良かった事／悪かった事
- 外部向けメッセージ
- ToDoリスト
- 構成は障害報告書と同じだが、内部のLearningに重きを置く点が特徴。下記のような内容で書くケースが多い。
- 障害対応時の組織体制についても定めておくのが重要。
- hashicorpが提唱する体制がいいケースとして上げられる。※参考
非機能要件について
- 非機能要件についてはIPAが定める非機能要求グレードがよく纏まっている。
- 非機能要件を決めるにあたって、まず最初にプロダクトの責任者と「サービスがどれくらい止まってもいいか」について合意形成することが重要。
DevOpsについて
- 組織がアプリケーションやサービスを迅速にリリースできるようになる事を目指す。
- 迅速なリリースは、エンドユーザーからの迅速なフィードバック及びそれに基づいた改善活動を可能にし、ひいては事業への貢献につながっていく。
③運用の例（Amazon／Google）
本セクションではAmazon／Google社の運用を例として解説いただきました。
改めて両社の取り組みを比較すると、
- Amazonはマイクロサービス化に伴いサービス単位のチームに完全に分割
- Googleは横断的に運用改善をおこなうためのチームを組成
と、対照的なアプローチをとっている事が印象に残りました。
また、会社の事業や文化にフィットする形で取り入れていく事が重要なのだと考えさせられました。
Amazon
- プロジェクトでは無くプロダクトにフォーカスし、いわゆるtwo-pizza-team*1を編成した。
- オンコール対応、KPIの策定／刈り取りやチームメンバーの雇用まで全てこのチーム内で行う。
- １つのチームは小さく、全責任を負えば素晴らしいが、そのためにはシステムをマイクロサービス化が不可欠だった。
- 最初から上手くデザインできるわけではない。必要になったらマイクロサービス化を行うなど段階を踏むのが重要。
- プロダクトの製造を行うロールと改善活動を全体としてみるロールを分割した。（通称SRE本）
- SREの信条
- エンジニアリングへの継続的な注力の保証
- サービスのSLOを下回ることなく、変更の速度の最大化を追求する
- モニタリング
- 緊急対応
- 変更管理
- 需要の予測とキャパシティランニング
- プロビジョニング
- 効率とパフォーマンス
④AWS環境の運用ガイド
最後のセクションでは、「Well-Architected」と呼ばれるAWSが考えるシステム運用のベストプラクティスについてご紹介いただきました。
AWSに関わらず、システムアーキテクトを行う際に考えなければいけないことが質問形式でまとまっているので非常に有用だと感じました。
またドキュメント以外にも、「AWS-Well-Architected-Tool」というAWSサービスがあります。こちらは現在プロビジョニングされているサービスがベストプラクティスに沿っているか確認してくれるAWSサービスです。
私はまだこのサービスを使った事が無いのですが、AWSソリューションアーキテクトの方からも「是非活用してください！」との事でしたので今後は怖がらずに積極的に活用していこうと思います！
AWS Well-Architected
- 設計原則と（質問と回答形式）のベストプラクティス集。
- [OPS1]運用の優先順位を決める要因は明確ですか？
- [OPS2]運用性を向上させるための設計を行っていますか？
- [OPS3]ワークロードが運用可能であることを、どのように確認していますか？
- [OPS4]システムが適切に運用されていることを、どのように確認していますか？
- [OPS5]運用中に発生するイベント（障害など）をどのように管理していますか？
- [OPS6]どのように運用を進化させていますか？
所感
今回、運用視点で注意すべきポイントやプラクティスを網羅的に知る事ができて、大変参考になりました。
ついつい開発サイドとしては開発のタスクに注力しすぎてこうした視点を失いがちなのですが、SREチームの力も借りながら、「ユーザーが困らない」運用設計について考えて行きたいと思います！
弊社のSREチームについては発足時のブログも公開されていますので、ぜひそちらもご覧いただけると嬉しいです！ techdo.mediado.jp
*1:ソフトウェア開発チームの人数を増やすと開発速度は指数関数的に低下する（ブルックスの法則）ため、開発チームを十分に小さなサイズ（2枚のピザをわけあえる程度）に維持するという考え方
