「SRE」の実践へ。「トイル」の元を断つなら、POLESTAR Automation！
ワイドテック プロダクト企画のYです。
今年も残すところ、半月余りとなりました。
昨年の今頃は、来年の今頃（今のことです）になればきっとコロナ禍も落ち着いて、地方や海外出張・旅行なんかも復活しているのかな、などと期待していたものですが、地方はともかく、まだ海外には実質的に行けない状況が続いています。
新型コロナウイルス全体の国内感染者数は秋以降落ち着いたものの、世界規模で見ると、まだまだ感染が沈静化したとは言い難く、11月に突如現れた新たな変異ウイルス「オミクロン」の拡大も、予断を許せません。
来年の今頃（2022年の今頃のことです）こそは、本来の意味で日常を取り戻せているとよいのですが。
さて、今回のテーマは、最近、ITインフラ運用界隈で目や耳にする機会の増えているキーワード「SRE（Site Reliability Engineering）」です。
SRE、そのままカタカナで「サイトリライアビリティエンジニアリング」、ないしは「サイト信頼性エンジニアリング」と紹介されることもあります。「サイト？ うちは自社内だけで、外に出しているサイトなんてやっていないのに」という方もいらっしゃるかと思いますが、まずはお読みいただければ幸いです。
■DevOpsとは？
SREを語る前に、まず押さえておきたいのが「DevOps（デブオプス）」です。
特にソフトウェア製品やサービスの開発を行う企業において、ITインフラ運用の自動化に携わられる方なら、実践するか否かにかかわらず、一度はお聞きになったことがあるのではと思います。
DevOpsの細かい定義はいろいろありますが、基本的にはDev（開発）とOps（運用）が一体となって協働し、さまざまなITの課題に取り組もうというものです。
とりわけ、Webの仕組みを通じてユーザーへのサービスが提供される、いわゆるXaaS（サービスとして提供される「何か」。最も有名なのは「サービスとして提供されるソフトウェア」を意味する「SaaS」でしょう）のようなクラウドサービスの開発においては、サービスの設計・開発を行う部門(Dev)と、情報システム部門と呼ばれることも多い、構築・運用部門(Ops)が、縦割りの組織で別々に運営され、連携を取ることもなく動くというのは、考えてみれば非効率的です。
しかし、大きな組織であればあるほど、必要なアプリケーションやミドルウェアをオンプレミスにインストールして開発を行い、そこから生み出される成果物もオンプレミスだった頃のレガシーな縦割り組織体系を引き摺っていることが、まだまだ多いようです。
横の連携が弱く、新たな開発成果が適用されるまでや、何か問題が発生した時の対応などに時間を要し、スピーディに解決しないケースも多かったかと思います。
このような課題の解決に向けて提唱されたのが、DevOpsです。このキーワードがある程度認知されたのは、2015～6年、ちょうどPOLESTAR Automationを世に出そうとしていた頃だったと思います。
■運用現場も「開発」からは逃れられない
DevOpsとセットで語られていたのが「継続的デプロイ（ないしは継続的デリバリー）」というワードで、「アジャイル開発」と結び付いています。綿密な事前計画（設計書・仕様書）、明確な日程や目標が設定された従来型の開発スタイル（ウォーターフォール開発と呼ばれます）を捨て、開発成果を直ちにサービス展開し、スピード感を持って、継続して改善を重ねていくのが、DevOpsです。
DevOpsの対象となるインフラは例外なくクラウドであり、DockerやKubernetesといったツールによってインフラをコンテナ化、オブジェクト化し、手順を自動化するのはAnsibleのような、主にCLIに依拠した自動化ツールです。
…と、ここまでの説明をお読みになって「うちはソフトウェア開発企業じゃないから」という方も多いかと思います。
DevOpsはあくまで開発側中心の視点からの運用協働であるといえ、対象となる課題も、XaaSを開発している企業にとってのものが大半だと思いますが、DX（デジタルトランスフォーメーション）に取り組み、推進するにあたっては、出来合いのパッケージやXaaSなどを利用するにしても、それを実際の業務に反映させ、より効果的なDXを推進して行くには「開発」が入ってくることになるはずです。
外部に丸投げでもしない限り、DevOpsからは逃れられない時代になると思いますし、外部に投げることは、スピード感の喪失という結果をもたらすことでしょう。
■DevOps実現への近道「SRE」
では、「開発」に縁の薄い企業がDevOpsに取り組む近道は、ないのでしょうか？
最近、DevOpsとの絡みで注目されているのが、冒頭で触れた「SRE」です。
SREの発祥地は、Google社です。同社の創業事業で、今も主力事業でもある、検索エンジンWebサイトの継続的開発・改善にあたって提唱された、開発と運用に対する方法論です。
SREのSが「サイト」なのは、検索エンジンサイトの開発・運営手法としてGoogle社内で創始されたことに由来しているわけですが、現在ではGmailやGoogleマップ、広告関連などのWebサービス、はてはGoogle Cloudを含むGoogleのあらゆるサービスに、SREの考え方が適用されているようです。
実はSREの歴史はDevOpsとさほど差はないか、あるいはSREの方がやや早いかもしれないぐらいの時期からなのですが、当初はあくまでGoogleの先進的事例として紹介されていました。
広く企業における運用の改善、DXを加速するアクセラレーターとして、SREが有効な手段であることが注目されるようになったのは、ITの世界的トレンドに影響力を持つ調査・コンサルティング企業であるGartner社が取り上げてからでしょう。
GartnerによるSREの定義は「回復力の高い分散システムを構築・運用するために使用される、システムおよびソフトウェア・エンジニアリングの複数の原則から成る方法論」だそうです。
GoogleにおけるSREチームは、運用管理を担当しているものの、開発系のエンジニアで構成されているそうです。約50%は本来の開発業務もやりながら、残りの約50%を運用に充てるという業務配分です。これはすなわち、DevOpsに他なりません。
つまり、SREとはDevOpsと対立するものではなく、DevOpsを実践するための行動方針、方法論こそ、SREといえます。
■「トイル」とは何か
近年のGoogleによるSREに関する説明では、「トイル」という概念が頻出するようになりました。
トイル(toil)という英単語には、単に「労働」の意味もありますが、「労苦」「辛苦」のようなニュアンスで使われることが多いようです。
Google Cloudのブログでは、トイルを「手作業、繰り返される、自動化が可能、戦術的、長期的な価値がない、サービスの成長に比例して増加する、といった特徴を持つ作業」と定義し、実例として、以下のようなものを挙げています。
– 割り当てリクエストの処理
– データベース スキーマ変更の適用
– 重要性の低いモニタリング アラートの確認
– プレイブックからのコマンドのコピーと貼り付け
つまり、単純ながら分量が多く、規模が拡大すればするほど増える雑多な作業を、トイルと定義しています。
前述のブログ記事では、高度なスキルを要する困難な作業は、トイルではないとしています。むしろ、そういった開発・運用上重要かつ有意義、付加価値の高い作業への取り組みを妨げる要因となっているのが、日常の運用作業におけるトイルの多さというわけです。
ちなみに、POLESTARではSREと運用自動化については「最新動向」のページなどでも情報公開を行っていますので、合わせてご覧くだされば幸いです。
■POLESTAR Automationこそ、SREに最適なツール
トイルとされる手作業、繰り返しの多い作業。確かに、それらに人を配置し、長期にわたってやり続けるとしても、何の価値もありませんし、何かを生み出しもしません。
トイルという用語は、今回初めて使用しましたが、自動化によってトイルを極限まで減少させたり、なくしたりすることは、まさにITインフラ運用自動化ソリューション・POLESTAR Automationが、発売以来訴求し続けてきたテーマでもあります。
運用自動化こそが、トイルの低減・撲滅、DevOps推進とDX加速の第一歩です。
POLESTAR Automationで、SREを始めてみませんか？
