ミクシィのSREがセキュリティに貢献する理由：特集：「DevSecOps」実現を支えるSRE（2）

　サイトの信頼性向上のために、運用の自動化や障害対応、パフォーマンス管理などに取り組む「Site Reliability Engineering」（SRE）を導入する企業が増えている。そんな中、SREがセキュリティに貢献する動きが広まりつつあるという。2020年1月に開催された「SRE NEXT 2020」で登壇したミクシィの清水勲氏の講演内容を要約してお伝えする。

「DevOps」と「SRE」の関係性

ミクシィ 清水勲氏

　SREの基礎知識として、まず清水氏がよく見聞きするという「DevOpsとSREの違い」について「その説明はGoogleのWebサイトに掲載されている」と引用して解説した。それによると、「DevOpsをオブジェクト指向におけるインタフェースと捉えると、クラスSREはDevOpsの実装である」「SREには、DevOpsのインタフェースの部分に限らない追加のプラクティスと推奨事項が含まれる」「より良いソフトウェアをより早く提供するために組織の障壁を打破するように設計された親密なものである」という（参考）。

　「つまり、SREとDevOpsは、ソフトウェアの開発と運用で競合する別々の物ではない。DevOpsが全てを含んでいるというよりは、DevOpsという概念をベースにSREが新しいプラクティスを追加しているといえる」（清水氏）

SREがセキュリティに取り組む背景

　では、なぜSREがセキュリティに貢献しているのか。その背景にあるのが信頼性とセキュリティの共通点だ。

　SREは取り組みの中で、レイテンシやスループット、可用性などのSLI（Service Level Indicator：サービスレベルインジケーター）を利用してSLO（Service Level Objective：サービスレベル目標）という数値を設定する。

　例えば、SLOとして99.95％の可用性を設定したサービスの場合、30日間で許容される停止時間は21.9分になる。この時間はエラーバジェット（Error Budget：エラー予算）という指標として管理され、サービス停止に応じて「エラーバジェットをどれくらい消費したか」を判断する。

　このエラーバジェットによって、SREが取り組む内容は変化する。エラーバジェットを使い切っていなければ、サービスに新たな機能を実装したり、堅牢（けんろう）なサービス作りに時間を割り当てたりする。一方で、エラーバジェットを超えるような場合、システムの可用性を阻害する原因を特定し、改善させていく必要がある。

　可用性を下げる原因は、劣化によるハードウェア故障、オペレーションエラー、情報伝達のミス、バグの混入、外部からの攻撃などさまざま考えられる。ハードウェアであれソフトウェアであれセキュリティであれ、サービスの可用性を下げる原因に応じた知識が必要になる。

　つまり、SLOやエラーバジェットなどを用いてサービスの信頼性に取り組むSREが、それらの指標を用いてセキュリティにも取り組むことで、どれだけセキュリティにコストをかければいいのか、セキュリティ対策をどう進めればよいのかなどの道筋を立てやすいというわけだ。

　「世界中で開催されているSREに関するカンファレンス『SREcon』では、セキュリティをテーマにした講演が採択されている他、2020年に発売が予定されているGoogleのエンジニアが執筆した『Building Secure & Reliable Systems』は信頼性とセキュリティをテーマにプラクティスをまとめているなど、SREとセキュリティが関連するテーマとして取り上げられています」（清水氏）

『Building Secure & Reliable Systems』のダウンロードページ

　『Building Secure Reliable Systems』の早期リリース版は、セキュリティと信頼性の共通項について「信頼性とセキュリティはソフトウェアやシステムのライフサイクルに必要不可欠な存在」「信頼性やセキュリティを両立したシステムを後から実装することは難しく、設計段階で考慮できていることが望ましい。一方で信頼性もセキュリティも問題が起きていないとコストをかけない領域で、問題が起きてから始めて深刻になる」などを挙げている。

SREに求められる大前提、ミクシィでの取り組み

　ではそもそもSREには何が求められるのだろうか。清水氏はミクシィでの事例を基に、SREが企業内で果たすべき役割とその大前提を説明した。

Copyright © ITmedia, Inc. All Rights Reserved.