イマドキの北米のSRE事情を垣間見た、NGINX Conf 2019のパネルディスカッション
既報の通り、弊社F5は今年NGINX社を買収完了し、毎年恒例のNGINX Confもお陰様でF5 / NGINX社員含め盛況に開催されました。2019年のNGINX Confでは、ほぼすべてのセッションをYoutubeチャンネルに公開しておりますのでそちらも合わせてご覧頂ければと思います。とは言え、当該イベントはグローバルイベントという位置づけであるものの日本を含むアジア地域からはほぼ参加者が居なかったことと、上記のセッションビデオは全部で50近くにのぼる膨大な情報量のため、ひとまず筆者の特にオススメのセッション情報まとめを当記事でさせて頂きたいと思います。
当該セッション「Site Reliability Engineering Panel - LinkedIn, Dell, and Gremlin」はそのタイトル通りパネルディスカションの形式になっています。NGINXのProduct Marketing責任者がモデレートする形で、Dell社、LinkedIn社、そしてカオスエンジニアリング実践プラットフォームを提供するGremlin社のSRE職に就く三名様にご登壇いただき、Site Reliability Engineering (SRE)という職務の現状について語っていただいています。主な要点を3つに絞るとこんな感じです。
- SRE の定義
結論から言うと、（少なくとも2019年9月時点では）まだ北米でもSREの定義は曖昧だったり、会社によって差異があるのが現状のようです。そんな中、パネリスト3名の共通解は「とにかくサイト・サービス・システムを稼働させ可用性を担保すること」でした。同時に、不具合やサービス断が発生した際には問題に対して技術的に深堀りし最速の復旧を目指す、且つ開発部隊がユーザ視点を失わないようにする、、、と、従来の認識ですと「運用部門？？」と感じてしまうほどです。そしてまさにパネリストの一人は「実際、運用部門の名称を変えてSRE発足と宣言する企業も見受けられる、、、が、あまりオススメしない（笑）」とも発言しています。
運用部門とSREの違いについては少し議論がなされましたが、SREたるポイントは運用部門ではなく開発部門のいち機能であること、またはユーザと対面してビジネス上のゴールを最優先するという点に結論としては集約されました。
- カオスエンジニアリングとFailure Injection
SREという職務に置いて重要な機能として挙げられるのがカオスエンジニアリングです。もともとこれはNetflix社が導入したことで注目された、本番稼働中のサービスにあえて擬似的な障害を起こし、耐障害性を強化する手法です。詳細はこちらの記事がオススメです。一言でいうと、システム障害に対する避難訓練に近い感覚をもっている、というのがパネリスト三名の共通点でした。ただ、避難訓練と最も異なるのは障害からの復旧、堅牢性、可用性などの視点で複数の数値化されたメトリックを設定している点です。
一方、Failure Injection とはSREが推し進める取り組みとして、こちらもまたまた元を辿るとNetflix社が2014年に紹介されました。サイトの不具合をシミュレートするメタデータを商用環境にプッシュし（ただし管理された状態として）、検証する手法です。前述のGremlin社はまさにこれを実行する環境をSaaSとして提供しています。
- SREというお仕事の評価基準とスキル
最後に取り上げたいのは、SREという職務の評価基準でした。一般的な指標としてはMTTD (Mean-time-to-Detect、平均不具合検出時間) や MTTR (Mean-time-to-Respond、平均対応開始時間) などが挙げられていました。一方、業界ごと、システムやサイトの特徴に応じて様々なメトリックが設定できるので個別にしっかりと定義していきたい点であるというのもパネリストの間で一致した見解です。「まず、自社の最優先するべきシステムを5つほど挙げて、それらの可用性を図る指標を出発点に定義を進めるのが良い」という提案も興味深く感じました。
SREに求められるスキルについては、一般的なシステムやネットワークの知識というより、対象となるシステムの知識を優先するのが良いという見解が意外な印象を受けました。例えばサイトがNGINXベースであれば当然NGINXの知識が最も重要になる、ということです。議論の中で個人的に最も興味深かった提案として、「SREは社内複数の部門でジョブローテーションし、必要なスキルを優先順位付けしつつ設定していくのがオススメ」というものがありました。ともすれば専門スキルを重要視する米国の職場環境からすれば、結構意外な考え方のように感じたのは私だけではない筈です。（むしろ、日本企業に取り入れやすいかも？）
また、SREのコミュニティに積極的に参画してヒントを得るのも重要である、というのも非常に納得の行くものでした。比較的新しい職務ということもあり、世の中の同様の職務従事者がどのように取り組んでいるかを知るのは効果的かも知れません。日本ではまず、オンラインのコミュニティ情報を日本語英語問わず収集するのがまずは良いかも知れません。
終わりに – 2020年にはSREは広がっていくか？
昔から業界内では、米国のトレンドは数年遅れで日本にもやってくると言われていました。現在はその流れも多様化し、もっと早く日本で盛り上がったり、RPAのように日本だけでガラパゴス現象的に盛り上がったり、米国以上にトピックによってはアジア市場が一部先行したりします。職場文化やキャリアの志向も日本は独特ですが、SREやDevOpsといった取り組みはデジタル革新の潮流に沿う形で無視できない流れになりつつあります。従来型のインフラ運用も今まで以上にクラウド化、自動化が進む見通しです。時代の流れに沿う一つの手法として、2020年はもしかしたら御社内のSRE定義に取り組むタイミングかもしれません。