SRE(サイトリライアビリティエンジニアリング:Site Reliability Engineering)とは、IT運用にソフトウェアエンジニアリング戦略を適用する手法です。これまでIT運用チームが手作業で行っていた作業をSRE専門チームが引き受け、ソフトウェアと自動化を活用して本番システムを管理し、問題解決を行います。
SREの最終目標は、拡張性かつ信頼性の高いソフトウェアシステムを構築し、それを維持することです。従来、運用チームが管理するマシンは数十台から多くても数百台程度であり、本番システムの管理やインシデント対応などの作業は手動で対応できました。しかし、システムの拡張やクラウドへの移行に伴い、システム管理者が担当するホストは数千台にまで増え、ほとんどの運用チームの処理能力を大きく上回るようになってしまいました。SREは、このようなシステムのガバナンスと最適化をソフトウェアコードで自動化することで、運用の問題を解決します。
SREは、サイトリライアビリティエンジニア(IT運用の経験もあるソフトウェアエンジニア)のチームと、クラウドアーキテクト、その他のEmbedded SREパートナー(Webサイトやアプリをエンドユーザーが常に利用できる状態に保つことを目的とする)によって実施されます。コーディングを行い、大規模なIT環境を管理するスキルを身につけているため、システム管理およびIT運用タスクの自動化と管理を監視する業務に非常に適した人材といえます。
SREはクラウドネイティブ環境において重要なプラクティスであり、新機能やサービスのリリースと可用性の維持を両立させるうえでも役立ちます。この記事では、SREの仕組み、DevOpsとの関係のほか、SREが組織にもたらすメリットについて説明します。
サイトリライアビリティエンジニアは、ソフトウェア開発とインシデント対応のライフサイクルの信頼性を確保することによって顧客価値を創出し、以下のメリットをもたらします。
すべてのSREプラクティスはシステムの信頼性を向上させることを目的としており、次の5つの主要なカテゴリに分類されます。
この取り組みの大きな部分を占めるのがデプロイ環境の整備です。これは、エンジニアと協力しながら新しいサービスのオブザーバビリティを確保するための活動です。これによって信頼性に関わる問題に対してよりプロアクティブかつ迅速なアプローチをとることができます。
SREのプラクティスには、分散システム内のすべてのサービスとアプリケーションの可視性と透明性が必要です。しかし、こうした環境で異なるサービスのパフォーマンスや可用性を測定するのは複雑な作業です。このプロセスをより取り組みやすいものにするために、Google社のSREチームは4つのゴールデンシグナルを提唱しました。これは、分散システムを効果的に監視するためのフレームワークの1つで、システムが健全であることを示すベンチマークを定めています。
DevOpsにおけるSREの役割は、DevOpsチームが開発したアプリやサービスをエンドユーザーが必要なときにいつでも使用できるようにしておくことです。SREとDevOpsは一括りに語られることが多いですが、これらは2つの異なる分野です。
DevOpsは、プラクティスとして、また一連の原則としての両側面から認識されています。プラクティスとしてのDevOpsは、ITデリバリーのためのアプローチであり、人、手法、ツールを連携させることで、開発チームと運用チームのサイロ化を解消します。
DevOpsは、その名前が示すように、アプリケーションのコードを作成するソフトウェア開発(Dev)と、それらのアプリケーションを本番稼動させてエンドユーザーに提供し、信頼性の維持を図るIT運用(Ops)との間を隔てるギャップを埋めることを目的としています。
原則としてのDevOps(DevOps文化)は、アジャイルの普及により生まれたものです。アジャイルは、段階的なデリバリー、チームコラボレーション、継続的な計画と学習に焦点を当て、より優れたソフトウェア開発プラクティスを導くための原則を確立しました。ソフトウェア開発とIT運用を連携させることで、DevOpsはソフトウェア開発ライフサイクル(SDLC)全体にわたってアジャイルの原則を拡張し、継続的な改善を目標としてワークフロー全体を最適化します。DevOpsがうまく機能すると、コーディングの反復と導入が迅速化するだけでなく、新しいアイデアを市場に投入するまでの時間が短縮され、バグが減少し、インフラの安定性が向上します。
SREは、DevOpsの原則において重要な機能を果たしており、プラクティスとしてのDevOpsとも重なる部分が多いものの、責任範囲はより限定的です。DevOpsでは、開発者が実際に製品のオーナーシップを持って運用することが求められます。しかし、開発者は絶えずアプリの新機能を開発しなければならないため、そういった取り組みが現実的ではない場合がほとんどです。
サイトリライアビリティエンジニアは、ソフトウェア開発とIT運用の両方の知識を活かして、デプロイ、設定、監視などのコードの管理を監督できます。大まかに言うと、SREは新しいソフトウェアや機能の迅速なデプロイ、およびITインフラの安定性を確保することで、開発と運用間の関係を強化します。
自動化による反復的な手作業の削減は、SREが重点的に取り組むべき課題です。そのために、サイトリライアビリティエンジニアは、ログ分析やパフォーマンス調整などの多くの自動化された運用タスクを活用しています。また、自動化は、MTTR (平均解決時間)の短縮、ダウンタイムやシステム停止による影響の軽減、さらには監視やアラート、パッチ適用などのインシデント対応アクティビティのための詳細なコンテキストを提供するためにも欠かせません。
自動化は、スピード、一貫性、効率、適応性が重要視される最新の開発環境では必須といえます。そして、最も重要なポイントは、日常業務の反復的な運用タスクの数が減り、SREチームのメンバーが新しいツールの作成、インフラの変更の監視、信頼性向上のためのその他のタスクの実行に集中できるようになることでしょう。
SREを効果的に実践するには、システムについて、またそれらがどのように連携しているかについて包括的な視点を持つことが必要です。サイトリライアビリティエンジニアは、システムを全体的に捉え、個々のコンポーネントだけでなく、それらの相互接続も重視しなければなりません。これを踏まえ、『The Site Reliability Workbook』に記載されている以下の7つの原則に従うことで、効果的にSREを実践することができます。
サイトリライアビリティエンジニアは、さまざまな責任を担っています。SREの一般的な役割には次のものがあります。
SREはDevOpsの活動と密接に連携しており、開発チームと運用チーム間には緊密なコミュニケーションが必要です。そのためこれらのチームが成功するには、信頼、連携、継続的改善の文化が不可欠です。
また、サイトリライアビリティエンジニアは、開発と運用のスキルを兼ね備えていることはもちろん、従来のソフトウェアエンジニアリングのツールとプラクティスを理解している必要があります。システムを包括的に把握することに加え、信頼性を高めるための新しい方法を取り入れる柔軟性も必要とされます。
さらに、SREには積極的なコミットメントが求められます。これは、単にツールやパッチを適用してシステムの欠陥を修正する作業ではありません。SREに求められているのは、文化を変えることや、運用に関する新しいプロセスや考え方を導入することです。他の取り組みと同様に、SREも最初は1人の推進者から始まるかもしれませんが、SREのプラクティスを成熟させていくためには、最終的に上層部からの賛同が必要となります。
稼動時間を長くして維持することは、あらゆる組織が取り組み続けている課題です。しかし、効果的なSREプロセスを有する企業はシステムの回復力が高く、その結果としてリリースの成功率も向上するため、競合他社よりも優位に立つことができます。インシデントが発生した場合でも、短い平均確認時間と平均修復時間(MTTA/MTTR)で対応できます。本番環境の問題の修正に要する時間が減ることで、開発、SRE、運用のすべてのチームは、それぞれの分野でビジネス価値の提供に注力できるようになります。その結果、信頼性はソフトウェア開発を滞らせる要因ではなく、ソフトウェア開発における機能の1つとなるのです。
IT/オブザーバビリティに関する予測
驚きに勝るものはありません。すべてを受け止める準備を整えておきましょう。Splunkのエキスパートが予測する、来年の重要なトレンドをご確認ください。
Splunkプラットフォームは、データを行動へとつなげる際に立ちはだかる障壁を取り除いて、オブザーバビリティチーム、IT運用チーム、セキュリティチームの能力を引き出し、組織のセキュリティ、レジリエンス(回復力)、イノベーションを強化します。
Splunkは、2003年に設立され、世界の21の地域で事業を展開し、7,500人以上の従業員が働くグローバル企業です。取得した特許数は850を超え、あらゆる環境間でデータを共有できるオープンで拡張性の高いプラットフォームを提供しています。Splunkプラットフォームを使用すれば、組織内のすべてのサービス間通信やビジネスプロセスをエンドツーエンドで可視化し、コンテキスト(把握したい要素) に基づいて状況を把握できます。Splunkなら、強力なデータ基盤の構築が可能です。
日本支社を2012年2月に開設し、東京の丸の内・大手町、大阪および名古屋にオフィスを構えており、すでに多くの日本企業にもご利用いただいています。
© 2005 - 2024 Splunk Inc. 無断複写・転載を禁じます。
© 2005 - 2024 Splunk Inc. 無断複写・転載を禁じます。