SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

AWSとAzureのマネージドサービスで実践カオスエンジニアリング

カオスエンジニアリングを安全に行うには? AWSとAzureのマネージドサービスの特徴を解説

AWSとAzureのマネージドサービスで実践カオスエンジニアリング 第1回

  • X ポスト
  • このエントリーをはてなブックマークに追加

 システムの信頼性を向上させる手法として「カオスエンジニアリング」が大きく注目されています。AWSからはFault Injection Simulator、Microsoft AzureからはChaos Studioといったカオスエンジニアリングの実施をサポートするマネージドサービスが登場し、これらの活用も広がっています。本連載では、これらのマネージドサービスの特徴を紹介しつつ、実際のカオスエンジニアリングの実践方法をご紹介します。

  • X ポスト
  • このエントリーをはてなブックマークに追加

はじめに

 連載「クラウドネイティブ時代の実践カオスエンジニアリング」では、カオスエンジニアリングの概要や求められる背景、実践的な障害挿入の仕方や気を付けておきたい注意点などについて、エンタープライズシステムの設計開発に長年従事してきた現場エンジニアの視点から解説しました。

 こうしたカオスエンジニアリングを効率的かつ安全に実施するためには、システムに関する多岐にわたる知識や経験が必要とされていましたが、クラウドベンダーからカオスエンジニアリングの実施をサポートするマネージドサービスが続々とリリースされてきており、カオスエンジニアリングの未経験者であっても簡単に挑戦しやすい状況が生まれています。

 しかしながら、システム停止時の影響が大きいエンタープライズのシステムに対しては、前述のようなカオスの挿入にはハードルを感じる方々も多いかと思います。

 本連載では、これからクラウドを活用したシステムを開発するエンジニアの皆様に向けて、AWSのFault Injection SimulatorおよびAzureのChaos Studioの2つのサービスを扱います。システムに対してどれだけ安全にカオスエンジニアリングを実施できるかという観点での比較や、実際にカオスの挿入を行う際に気を付けておくべき設定などについて、エンタープライズシステムの設計開発に長年従事してきた現場エンジニアが生の声をお届けします。

本連載のゴール

  • AWSのFault Injection SimulatorおよびAzureのChaos Studioの2つのサービスについて、安全なカオスエンジニアリングを実施できるという観点での特徴を理解する。
  • AWSのFault Injection Simulatorを使って基本的なパターンでのカオスエンジニアリングができる。
  • AzureのChaos Studioを使って基本的なパターンでのカオスエンジニアリングができる。

対象読者

  • 業務系システムの開発者・インフラ担当者
  • アプリケーション開発の経験がある人

カオスエンジニアリングが求められる背景

 DevOpsの流行もあり、追加開発を重ねていくシステムが増えています。長く追加開発を続けていくと、プログラム規模の増加やキーマンの離任といったことが起こりがちです。そうした状況だと各種モジュールの詳細仕様を把握しきれないままシステムが動作し続け、ある時何かのきっかけで大きな障害を起こしてしまうこともあり得ます。

 カオスエンジニアリングはこうした追加開発を行っているシステムに効果が高く、強制的な障害(カオス)の挿入により、未知の情報(リトライ機構の実装漏れやモジュール間の想定していない依存関係など)を明らかにできます。

 以前はカオスエンジニアリングの実施には、システムに関する多岐にわたる知識や経験が必要とされていましたが、クラウドベンダーからカオスエンジニアリングの実施をサポートするマネージドサービスが続々とリリースされてきており、未経験者でもカオスエンジニアリングに対するハードルは下がってきています。

 ただしシステムに対して安全にカオスの挿入を行うには、考慮すべき観点があります。

システムに対して安全にカオスの挿入を行う上で考慮すべき観点

 筆者が考慮すべき観点として考えているのは下記3点です。

  1. 定常状態の定義
  2. 影響範囲の限定
  3. 実験管理の負荷

定常状態の定義

 単純な指標(たとえばHTTPステータスが200など)でしか定常状態を定義できないと、システムの状況を大雑把にしか把握できません。システムの状況を細やかに把握するため、さまざまな視点で定常状態を定義できる指標が用意されているかというのは非常に重要です。加えて、定常状態から外れているかを検知する方法が多数存在することも重要になります。

影響範囲の限定

 システムへの安全なカオス挿入時にもっとも重要となるのが、影響範囲をコントロールすることです。この方法がどれだけ用意されているのかは安全なカオスエンジニアリングを実践する上で非常に重要です。

実験管理の負荷

 カオスエンジニアリングは多くの関係者を巻き込んで実施していくことになるため、実験実施の承認、実験結果の管理や共有が適切に実施できないと、システム稼働への影響を与えるような実験を実施してしまう可能性があります。安全性を高めるためには、実験管理を効率的に実施できる仕組みが用意されていることが重要になります。

次のページ
AWSとAzureのマネージドサービスの実装状況の比較

この記事は参考になりましたか?

  • X ポスト
  • このエントリーをはてなブックマークに追加
AWSとAzureのマネージドサービスで実践カオスエンジニアリング連載記事一覧

もっと読む

この記事の著者

奥村 康晃(株式会社NTTデータ)(オクムラ ヤスアキ)

 NTTデータ入社以来、クラウドサービスのAPIを連携させることで効率的な管理を可能とするクラウド管理プラットフォームの開発に従事。現在では、クラウド導入の技術コンサルや組織での技術戦略立案にも携わる。

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

石崎 奏(株式会社NTTデータ)(イシザキ ソウ)

 入社以来、NTTデータグループにおけるWindows/Linuxシステムの技術問合せ、トラブルシュート支援、アーキテクチャレビューに従事。現在は、Azureを中心としたクラウド技術者の能力開発や、グループ全体へのAzure活用支援にも携わる。Microsoft MVP for Azure (2022-) Twitter LinkedIn

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

伊藤 歩(株式会社NTTデータ)(イトウ アユム)

 入社以来、公共系システムの基盤開発に従事。昨今はパブリッククラウド ( AWS, Azure, GCP ) を中心にシステム開発を行う。現場でのシステム開発の他に NTT データグループの技術者育成施策を通じて Azure の技術検証を行い、Azureを強みとしている。

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

この記事は参考になりましたか?

この記事をシェア

  • X ポスト
  • このエントリーをはてなブックマークに追加
CodeZine(コードジン)
https://codezine.jp/article/detail/16172 2022/07/21 11:00

おすすめ

アクセスランキング

アクセスランキング

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング