SREによる構成変更がGmailなど広範囲な障害の引き金に。PublickeyTopクラウドSREによる構成変更がGmailなど広範囲な障害の引き金に。APIなどGoogleの広範囲なサービスで一部の機能が利用できなくなる、あるいは遅延が発生するなどの障害が発生しました。Dashboardのインシデント#19002」として報告しています。Engineer)による構成変更にあったと説明。Engineer)とは、高い信頼性や性能を発揮するシステムインフラを実現するため、運用においてもソフトウェア開発を積極的に行っていく方法もしくはそれを実践するエンジニアのことを指します。Treynor氏が提唱した、先進的な運用改善のアプローチとして注目されています。そのSREも人間が行うことですから、やはり完璧ではなかったわけです。下記はGoogleの障害報告から引用します。failure.根本原因2019年3月11日月曜日、GoogleのSREらが、社内のBlobサービスで使われているメタデータ用ストレージリソースの使用が劇的に増加している、というアラートを受け取る。12日火曜日、リソース使用量を減らすため、SREらがコンフィグレーションの変更を行ったが、これにはBlobデータの場所を参照するというシステムの重要な機能の一部を過負荷にしてしまうという副作用が含まれていた。負荷の増大は最終的に次々と障害を引き起こすことになった。内部ストレージが障害を引き起こしたことで、それに関連する複数の社外向けのクラウドサービスに影響が出たわけです。最終的にこの障害は、SREがマニュアル操作で過負荷による社内Blobサービスのトラフィックを削減し、収束させることとなります。次のような対策が報告されました。impact.こうしたタイプのサービス障害を避けるため、私たちはストレージサービスのリージョン間の分離を高め、これによってグローバル全体に障害の影響が及ばないようにする。load.また、高負荷による障害の波及が次々に広がらずに普及できるようにするため、より迅速なリソースのプロビジョニングができるように改善する。overload.さらに、システムの重要部に対する過負荷が構成変更によって起こらないように、ソフトウェアによる計測を実現する。メタデータストレージシステムの負荷低減動作を改善し、過負荷時でも適切に負荷が低下するようにする。SREが原因となった障害の対策にも、あるいはSREが原因の対策だからこそ、さらにしっかりとSREで対応していくことが報告から見えてくるようです。Niino(jniino)IT系の雑誌編集者、オンラインメディア発行人を経て独立。2009年にPublickeyを開始しました。Studioのロードマップを解説。「質とスピード」(後編)。「質とスピード」(前編)。2.7サポートを発表Google、Lookerの買収完了を発表。Enterprise、BtoBスタートアップ向け支援プログラムで無料提供と発表。usPublickeyについて/運営者についてお問い合わせ広告についてプライバシーポリシ。