私の仕事紹介：クラウド基盤のSRE（Site Reliability Engineering）

こんにちは。クラウドサービス1部基盤サービスデザイン課の田中です。

現在私達のチームは、いわゆるインフラチームとして「IIJ GIOインフラストラクチャーP2 Gen.2」のクラウド基盤の設計、構築および運用業務を担当しております。

本稿では、特にSRE（Site Reliability Engineering）の領域に焦点を当て、「私の仕事紹介」として業務の概要をお伝えさせていただきます。

「クラウド基盤のSREってどんな仕事なのだろう」とご興味を抱かれている方の一助となれば幸いです。

SREのコンセプトや用語に関する説明は本稿には含まれておりませんので、必要に応じて各種ネットや書籍の資料をご参照いただければと思います。

要約

• SREの適用において、クラウド基盤といわゆるクラウドネイティブなサービスとでは留意するべき相違点がある
  • クラウド基盤の場合、インプレースなアップグレードが要求されるコンポーネントが存在し、それらに対応する必要がある
    • いわゆるローリングアップデートやブルーグリーンデプロイメントの戦略が適用できない場面も多い
  • クラウド基盤の場合、お客様が利用する仮想マシンのメモリ利用率など、クラウドネイティブなサービスのSREとは異なる指標を分析する必要がある
  • クラウド基盤の場合、全てのオンコールアラートをSLI/SLOに準拠させることは、現実的には難しいと思われる
    • 停止すると致命的な影響が出るコンポーネントに対しては、トラディショナルな閾値ベースの監視とオンコールアラートを設けないといけない
• 具体的な業務としては、物理ホストのハイパーバイザのプロビジョニングなどがある
  • 1日で数十台の物理ホストのプロビジョニングを実現するため、自動化ツールと物理ホストのハードウェア管理インターフェースを連携させるシステムを独自に構築している
• クラウド基盤のSRE（Site Reliability Engineering）を担うということは、楽しい
  • クラウド基盤、すなわち大規模なオンプレミス環境の運用をソフトウェアエンジニアリングで解決する、というのはチャレンジングで楽しい

SREとクラウド基盤

SREという用語は昨今様々な文脈で使われますが、ここでは「ITサービスマネジメントをソフトウェアエンジニアリングの原理原則に基づいて実装するというアプローチ」という意味で使用いたします。

Google社が提唱したこのアプローチは、今ではシステム運用の注目するべきトレンドとなっています。

新規サービスの運用設計において、SREのコンセプトを考慮することは必須、とまで言っても過言ではないかもしれません。

しかし、現在広く世の中に知られているSREのプラクティスは、クラウドネイティブの文脈で語られるものが比較的多いのではないかと感じています。

すなわち、パブリッククラウドサービスが提供するインフラストラクチャを利用する、という前提でのSREの適用です。

具体例としては、コンテナや仮想マシンの運用にイミュータブルインフラストラクチャのコンセプトを取り入れ、システムへの変更の度にインスタンスを使い捨てることで、スケーラビリティと信頼性を向上させる、というプラクティスが挙げられます。

このようなプラクティスは、そのままではクラウド基盤の運用に対して適用することはできません。

システムへの変更の度に、コンテナや仮想マシンを使い捨てるように物理サーバを廃棄して購入し直す、などということは現実的では無いからです（ただし、部分的にであれば、イミュータブルインフラストラクチャのコンセプトから恩恵を受けられる箇所はあります）

このように、クラウド基盤とクラウドネイティブなサービスとの間に差異がある中で、クラウドの基盤を運用する上でSREのプラクティスがどう適用されるか、というテーマはあまり知られていないのではないかと思います。

クラウド基盤とクラウドネイティブのSRE観点での違い

当たり前ですが、SREはクラウド基盤の運用にも問題なく適用できます。

そもそも、このアプローチを提唱したGoogle社は著名なパブリッククラウドサービスを提供しているわけですから、適用できないわけがありません。

しかし、前述の通り、現在広く知られているプラクティスに倣おうとする際には、それがクラウドネイティブなサービスを前提としていないか、という点を考慮する必要があります。

私達のチームが見出した留意点はここには書ききれませんが、具体例としては下記のようなものが挙げられます。

インプレースなアップグレード

広く知られているアップデート（もしくはリリース）に関するSREのプラクティスとして、ローリングアップデートやブルーグリーンデプロイメント戦略があります。

ローリングアップデートはクラスタを構成するコンポーネントを徐々に新しいバージョンのものへ入れ替えていく手法であり、ブルーグリーンデプロイメントは現環境と新環境を2系統用意の上で経路を切り替える手法です。

いずれも、ダウンタイムを最小化した上で安全にアップデートを実施するための洗練されたプラクティスです。

 

しかし、クラウド基盤を構成する特定のコンポーネントをアップグレードする際は、プロダクトの仕様上システムのダウンタイムが避けられないために、このようなプラクティスを採用できない場合があります。

そのようなコンポーネントに対しては、深夜帯にメンテナンスウィンドウを設けた上でアップグレードを行うことになります。

 

私達のチームでは、このようなインプレースなアップグレードに際しては、バックアップとスナップショットを取得することでメンテナンスの安全性向上に努めています。

バックアップを取得することで、万が一アップグレードで致命的なトラブルが発生してもリストアにより切り戻すことができます。

また、対象が仮想化されている場合は、より迅速に切り戻せるようスナップショットも取得するようにしています。

スナップショットとは、仮想マシンの特定時点の状態を取得・保持する仮想化基盤システムの機能です。

特定時点がそのまま保存されているため、切り戻しはその時点への復元、という形で非常にシンプルに行えます。

バックアップとスナップショットを取得することで、もし致命的なトラブルが発生したらスナップショットからの迅速な復元を試み、それも何らかの理由で失敗したらバックアップからリストアする、という2重のリカバリプランを策定しています。

これにより、インプレースなアップグレードでも安全に行えるようにしています。

私達のチームでは、このような工夫をクラウド基盤のSREのプラクティスとしてさらに昇華させるため、バックアップ取得やリストアのプロセスを自動化するなどの取り組みも行っています。

自動化のイメージにつきましては、過去私達のチームの山本が投稿した記事がありますので、よろしければご覧ください。

VMwareの運用シーンでもできるCI/CD

クラウド基盤特有の指標計測

SREに関するプラクティスのうち最も重要なものの1つはSLI/SLOのコンセプトです。

お客様にとってサービスが正常に動作しているかを判断するための指標がSLIであり、そのSLIの目標値、すなわちお客様の観点でサービスが正常に動作していない状態の許容限度がSLOです。

このSLI/SLOが存在することで、SREチームは他のステークホルダーに対して、データに基づく品質レベルの提示や課題の優先度付けに関する交渉を行うことができます。

 

クラウドネイティブなサービスの場合、この指標はAPIアクセスの成否やデータ処理パイプラインの精度、という切り口になることが多いのではないかと思います。

クラウド基盤の場合もこれらのような指標は重要ですが、より重要な指標としては下記のようなものが挙げられます。

• お客様がご利用される仮想マシンにおいて、クラウド基盤観点でメモリやCPUのオーバーコミット状態になっている時間
• お客様がご利用される仮想マシンにおいて、ディスクに対する読み書きが遅延している時間

クラウド基盤のサービスにおいて重要なことは、お客様に対してコンピューティングリソースが正常に提供できているか、という点です。

この指標の見極めを見誤り、世の中に広く知られているやり方だからという理由でAPIアクセス成否の計測で満足してしまうと、「クラウド基盤のAPIアクセスは問題ないが、お客様の仮想マシンのパフォーマンスが半分になっている」という状態でも品質レベルに問題が無い、などという判断を下してしまうことになります。

私達のチームはこのような誤りに陥らないよう注意しながら、クラウド基盤としてどのような指標がお客様にとって重要かを議論し、日々SLI/SLOのアップデートを続けています。

クラウド基盤に対するトラディショナルな監視

最近はSLI/SLOとシステムの監視が結びつけられて語られることも多くなりました。

前述の通り、SLOは正常に動作していない状態の許容限度と言えますから、このSLO違反に抵触する可能性があるかという観点をオンコールアラートの基準とすることは合理的です。

 

しかし、私達のチームでは、クラウド基盤の監視における全てのオンコールアラートをSLI/SLOに準拠させることは現実的ではないと判断し、そのような監視設計はしておりません。

「インプレースなアップグレード」で記載した内容とも関連しますが、クラウド基盤を構成する特定のコンポーネントでは、停止すると即座にシステムのダウンタイムに直結するものが一定数存在します。

そのようなコンポーネントの監視においては「ごく少数の失敗を許容する」というSLOの考えは馴染まず、予防的なオンコールアラートを設定する必要があります。

 

具体例としては、ディスク容量の監視が挙げられます。

特定のコンポーネントに対してディスク容量を監視し、ディスクフルになる前に一定の閾値でオンコールアラートを発報する、というトラディショナルな監視です。

私達のチームでは、このようなディスク容量の監視も設定しています。

ディスクフルになるとそのコンポーネント上で動くサービスが突然異常終了し致命的な影響が出る、という挙動が予想される状況だとします。

そんな中で、いくらディスクフルになる前までは問題なく動作するといっても、そうなった後でしかオンコールアラートは発報しないという選択肢はあり得ないことは自明かと思います。

 

私達のチームでは、オンコールアラートの設定基準についてSLI/SLOへの準拠にこだわらず、もう少し広く「お客様にサービスを提供する上でのリスク増加をどのような指標で捉えるべきか」という切り口で見ています。

そのような切り口であれば、前述のディスク容量監視も、お客様の仮想マシンのディスク読み書き遅延も、等しくリスクの増加としてオンコールアラートを発報するべきと判断できます。

こうしたオンコールアラート設定のための尺度を、SLI/SLOのような明快な尺度で表すにはどうすれば良いか、は未だに私達のチームでも議論が続いております。

いずれ、クラウド基盤のSREのプラクティスとしてまとめられればと考えている次第です。

業務の具体例：ハイパーバイザのプロビジョニング

本章では、私達のチームが担当する業務の具体例として、ハイパーバイザのプロビジョニングについて簡単に説明します。

サービスの成長に伴うリソース増強は、SREの担当領域として一般的かと思います。

しかし、クラウドネイティブなサービスの場合はAPI経由で容易にスケーリングできるのに対し、クラウド基盤の場合は物理機材の調達を含む複雑なプロセスを確立しなければなりません。

お客様がご利用される仮想マシン数が増加しCPU・メモリリソース消費量が上昇することで、クラウド基盤全体の利用可能なリソースが減少するため、それを増強する、というイメージです。

すなわち、クラウド基盤に対して、ハイパーバイザがインストールされた物理ホストを増設する必要があります。

 

私達のチームでは、クラウド基盤のSREプラクティスの一環として、特に時間がかかる繰り返し作業であるハイパーバイザのプロビジョニング工程を自動化しています。

この自動化により、プロビジョニングしたい物理ホスト群のホスト名を指定してインストールボタンを一回押すだけで、数十台の物理ホストをクラウド基盤へ追加することが可能になっています。

 

自動化の裏で実行されるプロセスは、下記のような流れになっています。

• インストールボタンを押すと、ハイパーバイザの自動プロビジョニングシステム（以降プロビジョニングシステムと呼称）に対して、物理ホストのホスト名とそれに紐づくプロビジョニングに必要な情報（MACアドレスなど）が通知される
  • このプロビジョニングシステムの実体は、PXEブートサーバに独自のAPIを実装したものです
  • 物理ホストに紐づく情報は、内部でAnsibleのインベントリ変数として管理されているため、ホスト名を指定するだけで併せてプロビジョニングシステムに通知することができます
• プロビジョニングシステムは、物理ホストのBMC（Baseboard Management Controller）のIPアドレスにアクセスし、PXEによるネットワークブートの設定と電源オンの操作を実行する
  • BMCとはハードウェア管理のための専用プロセッサであり、OSのインストール状態に関わらずリモートからのBIOS設定変更などを可能にします
• 物理ホストは、PXEによるブート処理を開始し、プロビジョニングシステムからハイパーバイザのイメージを取得の上でインストールを開始する
  • この時、kickstartにより初回インストール時のセットアップも併せて行われます
• プロビジョニングシステムは、物理ホストのインストールの状態をポーリングで監視する
• プロビジョニングシステムは、ハイパーバイザのインストールが完了した物理ホストを、クラウド基盤を統合管理するコンポーネントに登録しリソースとして利用可能にする

PXEブートによるインストールからクラウド基盤への登録まで、レイヤをまたいで自動化することで、一貫したプロビジョニングのワークフローが構築できていることがお分かりいただけるかと思います。

 

私達のチームでは、上記の自動化を更に洗練させるため、関連する他の作業工程もこのワークフローに連携させることを検討しております。

具体的には、クラウド基盤への追加後、対象の物理ホストに対する監視の設定投入までを一貫して自動で行えないか、という点を改善課題として考えております。

現在の監視システムでは、クラウド基盤に物理ホストが追加された後、ネットワークディスカバリが実行されることで、発見された物理ホストに紐づく監視の設定投入が行われていました。

しかし、クラウド基盤の規模が拡大することで、このネットワークディスカバリの時間が長期化し始め、実際にお客様が物理ホストを利用可能になるまでのリードタイム悪化が目立つようになりました。

そのため、このネットワークディスカバリへの依存関係を解消し、プロビジョニングのワークフロー側に統合することで、利用可能になるまでのリードタイムを短縮できればと考えております。

もしこうした仕事の内容に興味がございましたら・・・

いかがでしたでしょうか。

もしかすると、上記の内容をご覧いただき、私達のチームがSREとして非常に完成度の高い運用を実現できている、という印象を抱かれたかもしれません。

しかし、実際のところはまだまだ課題も多く、解決するのが楽しみな問題もあります。

 

クラウド基盤のSRE（Site Reliability Engineering）を担うということは、技術的に楽しく、社会への貢献度も高いやりがいある仕事です。

もし上記のような技術要素や業務内容にご興味がございましたら、弊社人材募集への応募をご検討いただけますと幸いです。一緒に働きましょう。

---

IIJ社員がお送りする、私の仕事紹介。
ほかの業種紹介もありますので、気になる方はこちらもチェックください。

【特集】私の仕事紹介