Techトレンド Vol.851

「カオスエンジニアリングはサーバーを落とすことではない」クックパッドから学ぶ、マイクロサービス化への最適な障害対策

昨年、バズワードになった「カオスエンジニアリング」。

本番稼働中のサービスにあえて擬似的な障害を起こすことで、システムがどのように振る舞うかを把握し、実際の障害に備える手法のことだ。世界に1億人超のユーザーを抱えるネット動画配信サービス『Netflix』が導入したことで、注目されるようになった。

クックパッドが2018年8月2日に公開したブログエントリ「Chaos Engineering やっていく宣言」でも話題になり、好奇心をくすぐられたエンジニアも少なくないだろう。

しかし、カオスエンジニアリングを日本企業でいち早く導入した、クックパッドの技術部・SREグループの小杉山 拓弥さんは、「カオスエンジニアリング=サーバーを落とすことではない」と話す。

Cookpad TechConf 2019』(2019年2月27日・恵比寿ガーデンプレイス ザ・ガーデンホール)で、小杉山さんが語った内容から、カオスエンジニアリングを導入する際のヒントについて学びたい。

クックパッド株式会社
技術部 SREグループ
小杉山 拓弥さん

2018年に新卒入社、技術部 SREグループに所属。自律的なインフラストラクチャを構築し、失職することを目指している

マイクロサービスアーキテクチャでのレジリエンスの必要性

SREエンジニアとして、同社のシステム耐障害性の向上に取り組んでいる小杉山さんは、カオスエンジニアリング導入の理由について、「マイクロサービスアーキテクチャの移行」にあると話す。

(※)マイクロサービスアーキテクチャ:サービスの組み合わせで全体のサービスを構成するアーキテクチャ。複雑なサービスロジックを適切な粒度のサービスとして切り離すことにより、個々のサービスのメンテナンス性を高めたり独立したデプロイを可能にする。

「クックパッドでは、2014年頃から巨大なモノレポによる疲弊や組織構造の変化を起点として、マイクロサービスアーキテクチャの移行・拡大を進め、CI の高速化や独立したデプロイなどの利点を享受しました。しかし、分散システムになると、システムの複雑性は増します。サーバー上で障害が発生したとき、原因がどこにあるのかつきとめにくく、障害が伝播するなどの弊害も生じました」

複数のサービスに分割することにより1つ1つはシンプルになるが、サービス全体としては複雑になり、ネットワークといった関心事も増す。同社の本番環境で動作しているマイクロサービス群も大小80以上あり、すべての障害の影響範囲を把握することが難しくなっていった。

しかし、多くのユーザーを抱えるtoCサービスを運営する企業では、想定外のトラブルに対して迅速な対処ができないと、一瞬で競合にユーザーを奪われてしまう危険性がある。

障害をゼロにすることは不可能。障害が起こる前提で、どこかで障害が起きた場合でも可用性を保つシステム、レジリエンスなシステムを設計することが重要になってくる。システムの弱い部分を発見し、よりシステムの可用性を高める取り組みがカオスエンジニアリングだ。

「カオスエンジニアリングは本番環境を壊すことを目的としているわけではありません。あくまでも手段であって、可用性の高いシステムを作るために必要な障害対策です。マイクロサービスで発生する障害に対するプロアクティブなアプローチとして、クックパッドではカオスエンジニアリングが必要になりました」

マイクロサービスアーキテクチャとセットで考えるべきアプローチ

では、同社ではカオスエンジニアリング導入をどのように進めたのだろうか。小杉山さんは、ユーザーへの影響を最小限にするため、『Known unknowns』という概念を用いて、システム障害の種類を分類するところから始めたという。

小杉山さんが話す『Known unknowns』の概念には、3つの考え方がある。一つ目の『Known Knowns』は、既に知っていること。例えば、障害が起きたときに、システムAが応答しなくなることを知っていて、システムBへの影響も把握しているということ。2つ目は、『Known unknowns』。システムAが応答できないことは知っているが、他のシステムへの影響は分からないこと。3つ目に、『Unknown unknowns』。システムBが応答しなくなることを考えたことすらなく、他のシステムへの影響も予測できないこと。

「カオスエンジニアリングの出発点は、『Known unknowns』の検証です。なぜなら、『Known unknowns』を解決しないまま本番環境で障害を起こすということは、ユーザーに与える悪影響を認知した上で、被害を与えるということになります。これでは、悪影響を受けたユーザに説明のしようがありません」

カオスエンジニアリングは、場合によっては本番環境に障害を起こすため、ユーザーに悪影響を与えてしまう危険性もある。それでも導入する必要があるかは、「まずどの問題を解決したいのかを慎重に考えるべき」だと小杉山さんは強調する。

「もっとも重要なことはサービスの安定稼動です。単純なモノリシックサービス(集中システム)であれば、無理にカオスエンジニアリングを適用することは不要で、従来の耐障害試験をしっかり行うことのほうが大切です。カオスエンジニアリングはあくまで、マイクロサービスアーキテクチャとセットで考えるべきアプローチだと思います」

>>講演資料・動画はこちら

取材・文/君和田 郁弥 画像提供/クックパッド

この記事が気に入ったらいいね!しよう

エンジニアtypeの最新情報をお届けします

RELATED POSTS関連記事

JOB BOARD編集部おすすめ求人

この記事に関連する求人・キャリア特集


記事検索

サイトマップ



記事ランキング

【ひろゆき】人間関係のストレスで潰れる前にエンジニアが“諦めていい”3つのこと「他人ルールからさっさと降りて、自分ルールで生きればいい」

【ひろゆき】人間関係のストレスで潰れる前にエンジニアが“諦め...

DeNA・メルカリ・CA人事が証言! スキルはあるのに“面接で落ちる”エンジニアに足りないもの

DeNA・メルカリ・CA人事が証言! スキルはあるのに“面接...

SIerって本当にヤバいの? ひろゆきが語る、業界ごと沈まないためのキャリア戦略

SIerって本当にヤバいの? ひろゆきが語る、業界ごと沈まな...

国籍も年齢もバラバラな開発チームをどうまとめる? 29歳、LINE最年少役員が貫く多国籍チームマネジメントのポリシー

国籍も年齢もバラバラな開発チームをどうまとめる? 29歳、L...

「働き方改革」で増える余暇時間を、エンジニアはどう活用すべきか?【連載:澤円】

「働き方改革」で増える余暇時間を、エンジニアはどう活用すべき...

TAGS

「type転職エージェント」無料転職サポートのご案内