GoogleのSREを日本流にアレンジする(ホワイトペーパー Vol.10)

お役立ち資料/ホワイトペーパー >

GoogleのSREを日本流にアレンジする(ホワイトペーパー Vol.10)

GoogleのSREを日本流にアレンジする

1.外注に依存している日本の情シス

SRE(Site Reliability Engineering)は、Googleが提唱するシステム運用の方法論で、開発スキルを持つSREエンジニアがシステムの価値向上を目指し、利便性と安定性向上のため、運用における問題や障害対応に取り組みます。そのための武器はソフトウェア・エンジニアリングを活用した自動化で、これにより、正確性と効率性を実現します。
しかし、日本では開発スキルを持つ運用エンジニアを容易に採用できるわけではありません。そもそも、日々の運用はITベンダーに依存しており、別世界の話だと思われる人も多いのではないでしょうか。

その背景は、米国と日本における情シスの役割が大きく異なることが原因だと思われます。
図1に示すように、IT人材の約7割がITベンダーに集中する日本と、対照的に約7割がユーザー企業に属する米国。日本では多くの企業が開発をITベンダーに任せていますが、米国では自社で開発を行います。米国にもITベンダーは存在しますが、不足する開発リソースの一時的な補充としての活用にとどまります。
日本では運用までもITベンダーに委託することが多いため、情シスの役割は外注の管理が主体となります。自社内で開発リソースを保有しているのは、限られた企業のみです。

IT企業とそれ以外に所属する情報処理・通信に携わる人材の割合
<図1> IT企業とそれ以外に所属する情報処理・通信に携わる人材の割合

出所:IT人材白書2017


米国の場合、自社で企画から開発、運用まで行うため、Google が実践しているようなSREのチームを構成しやすいのです。
しかし開発リソースを持たず、外部のITベンダーに開発を委託し、運用も任せているような日本の情シスでは、SREと言ってもピンとこないのは当然です。


2.DX対策やセキュリティ対策、コスト削減。これからの時代、多くのことが情シスに求められる

昨今のサイバー攻撃による情報流出事故の多発。サイバーセキュリティ対策の重要性が高まり、政府が経営陣にも自社のITシステムやセキュリティ対策の状況を把握することを求めるようになってきました*。
*NISC 2022年3月1日付「サイバーセキュリティ対策の強化について」
また、ITシステムの維持運用コストが、IT予算の90%以上を占めるようになると経産省が『2025年の崖**』で警鐘を鳴らしているように、より効率的でコストを抑えた運用が求められるようになってきました。
**経産省「DXレポート ~ITシステム「2025年の崖」克服とDXの本格的な展開~」
このように、情シスとしてはこれまでと同じ運用体制、管理体制では立ち行かなくなりつつあり、運用業務の抜本的な改革に向け、今までの取り組みを見直さなければならない時期が迫っています。
このような背景から、GoogleのSREをそのまま適用するのではなく、日本流にアレンジする考え方が必要になるのです。


3.日本版SREを進めるために

多くの企業ではITベンダーに運用を全部または一部を委託しています。そこから一足飛びに自社主体の運用に転換を図るというのは、スキル的にもコスト的にもハードルが高すぎます。
そこで、段階的にスキルをつけていき、現状の把握から作業内容、委託コストの正しい評価、最終的に情シス自身が主体的に運用することができるようにする進め方こそ、現実的だと考えます。
そして、現状のスキルギャップを埋めるためのキーとなるのが、運用自動化ツールです。
日本版SREの実現に向けた進め方を、図2に示します。

日本における現状の課題とSREへの取り組みへ流れ
<図2> 日本における現状の課題とSREへの取り組みへ流れ

出典:ワイドテック


まず、自社のITシステムがどうなっているのか、委託しているITベンダーに任せっきりにするのではなく、自社でも構成情報や資産状況を把握し、現状リソースの可視化を進めます。
ハードウェア構成やOS、アプリケーションなどの種類やバージョン、パッチの適用状況などを知ることは、リソース利用状況の正確な把握だけでなく、サイバーセキュリティ対策にも役立ちます。また、リソース情報の把握は、クラウド移行に向けた検討や試算にも有効です。
このほか、利用しているソフトウェアがライセンス契約内容に違反していないかの確認も行います。よくあるのは、利用中のCPUコア数が、契約内容を超えて違反状態となっているケースです。

次に、委託しているITベンダーが行っている作業方法と内容を共有することです。ツールを利用している場合もありますし、手作業の場合もあります。ツールを使っている場合は、わかり易く操作性に優れ、自社でも使えるような、属人化しにくいものを採用してもらうよう依頼する必要があります。これは契約更新のタイミングに行います。委託するITベンダーが手作業で対応しているようでは、効果的なコスト削減は見込めません。 ヒューマンエラーをなくし、効率的に作業が行えるような自動化ツールの導入を目指すべきです。これにより、自社だけでもツールを利用して簡単な情報収集やレポーティング作成が可能になります。

そして、最も難度が高い「ソフトウェア・エンジニアリングスキルの不足」は、自動化ツールが提供しているスクリプト・ライブラリの活用で、最初の段階を凌ぎます。ゼロから自動化スクリプトを作成するのではなく、ライブラリに登録されたベストプラクティスを活用することで立ち上がりが早くなりますし、その内容を学ぶことで、新たなスクリプトを開発することが可能になります。

このように、一般的に開発スキルに自信のない日本の情シス担当者が、自動化に取り組み、ミスをなくし効率性を高めるためには、Googleが進めているエンジニアありきの方法ではなく、自動化ツールを上手く活用してスキルを補完する方法が現実的だと考えます。


4.日本版SREに求められる要件

それでは、具体的にはどのように進めればよいのでしょうか。
既に監視ツールが日々の運用に欠かせなくなっている企業は多いと思いますが、構成管理ツールを導入して作業の自動化や障害対応まで行っているところは、まだ少ないようです。
今後は監視と構成管理を運用の両輪として考え、自動化を検討していきます。
構成管理ツールは、スクリプトを利用した構成情報の収集から自動化ジョブの実行までをカバーするものです。単にスクリプトを流し込むだけのものから、構成情報の自動収集や便利なスクリプト開発環境を提供しているものまで多岐にわたります。ポイントは、ソフトウェア・エンジニアリングスキルが弱い運用担当者でもフラストレーションを溜めることなく作業が可能なこと。すなわち、わかりやすく、使いやすいことです。これによりトイル(=労苦)を削減します。
また、GoogleのようにSREチームがスクリプトを書いてどんどん自動化を進めていくようなわけには行きませんので、自動化スクリプト・ライブラリを活用できれば、スタートダッシュが可能です。
対象デバイスの選択やスケジュール、結果通知など、できるだけコアとなるスクリプト部分以外は簡単に設定できたほうが開発のための負担を減らすことができます。
さらに、自動で収集してきた構成情報や資産情報を、ダッシュボードやレポーティングツールで表示や印刷ができると可視化に便利です。
そして、障害対応にあたっては監視ツールと構成管理ツールが有機的に連携できるようなREST-APIのインターフェースがあると拡張性が高まります。


5.日本版SREに適しているPOLESTAR AUTOMATION

このような要件を満足する構成管理ツールの1つとして、POLESTAR Automationが挙げられます。

  • GUI操作なので「使いやすさ」「わかりやすさ」に優れ、ほとんどの操作をマウスだけで行える
  • サーバーやネットワーク機器の構成情報を自動収集し、その結果をダッシュボードに表示。集計結果を標準のレポーティングツールで出力できる
  • 1,100種類以上のサンプルジョブを無償提供しており、自動化の即戦力としての活用や自動化スクリプトの理解・学習に最適

そして、Zabbixなどの監視ツールとPOLESTAR Automationで日本版SREを実現します。

GoogleのSREが改善責任を持つ対象と自動化ツールでの代替
<図3> GoogleのSREが改善責任を持つ対象と自動化ツールでの代替

出典:Google社資料にワイドテックが加筆


  • POLESTAR Automationは、コストパフォーマンスに優れ、管理対象サーバーあたり12,000円(税別)/年、(最低10ノード。10ノード単位で販売 100ノードならば120万円ソフトウェア保守込み 税別)で、小さく始めて大きく育てることができる

自動化は難しいものではありません。ツールを活用してチャレンジし、日本版SREに取り組んでいただくことをおすすめします。