0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

インフラ設計の原則 ①

Last updated at Posted at 2024-12-16

自己復旧の設計

分散システムでは、ハードウェア障害やネットワークの一時的な問題など、さまざまな障害が発生する可能性があります。これらの障害に備え、アプリケーションを自己復旧できるように設計することが重要です。以下に、自己復旧を実現するための推奨事項をまとめます。

推奨事項

1. 非同期で通信する分離コンポーネントを使用する

コンポーネント(フロントエンド、バックエンド、データベースなど)間の依存性を減らし、連鎖的な障害を防ぐため、イベント駆動の非同期通信を採用する。

AWS サービス例
  • Amazon SQS:
    コンポーネント間の非同期メッセージングを実現し、システムの結合度を低減する

  • Amazon SNS:
    イベント駆動の非同期通信をサポートし、複数のコンポーネントへの通信を可能にする

2. 失敗した操作の再試行

一時的なネットワーク障害やデータベース接続の問題に対処するため、再試行ロジックを実装する。

AWS サービス例
  • AWS SDK:
    AWS SDK には自動再試行機能が組み込まれており、設定により再試行回数や待機時間を調整できる

3. リモートサービスの保護 (サーキットブレーカー)

継続的な障害時にシステム全体への影響を最小限に抑えるため、サーキットブレーカーパターンを使用して、失敗する可能性が高い操作を一時的に停止する。

サーキットブレーカー:
  1. 通常 (クローズ状態):
    • システムはリモートサービスや依存するコンポーネントに通常通りリクエストを送信
    • リクエストが成功すればそのまま動作
  2. エラー発生時 (オープン状態):
    • 一定回数の失敗が発生すると、リクエストを停止 (オープン状態)
    • オープン状態では、一定期間リクエストを遮断して、エラーを防ぐ
  3. 回復確認 (ハーフオープン状態)
    • オープン状態が一定時間経過した後、少数のリクエストを再試行
    • 成功すれば通常状態に戻り、失敗すれば再度オープン状態に遷移
AWS サービス例
  • AWS Lambda と AWS Step Functions:
    Lambda でサーキットブレーカーの各ステップで実行される処理ロジックを実装し、Step Functions でサーキットブレーカーパターン全体の状態遷移や分岐を管理する

4. 重要なリソースの分離 (バルクヘッド)

システムを独立したグループに分割し、1 つの部分での障害が全体に影響を与えないようにする。

AWS サービス例
  • Amazon ECS や Amazon EKS:
    コンテナを使用して、異なる機能を持つサービスを分離し、1 つのサービスの障害が他に影響を与えないようにする

5. 負荷平準化

キューを使用して作業項目を非同期的に処理し、突然のトラフィック増加によるバックエンドサービスへの負荷を平準化する。

AWS サービス例
  • Amazon SQS:
    キューイングを利用して、突発的なリクエスト増加時にも負荷を平準化する
  • Amazon Kinesis:
    リアルタイムデータストリーミングを処理し、負荷分散する

6. フェイルオーバーの実装

障害発生時に別のインスタンスやリージョンに自動的に切り替える仕組みを構築し、高可用性を確保する。

AWS サービス例
  • Amazon Route 53:
    ヘルスチェックとフェイルオーバー機能を使用して、障害発生時にトラフィックを健全なエンドポイントに自動的に切り替える

  • Amazon RDS のマルチ AZ 配置:
    データベースの高可用性を確保し、障害児に自動フェールオーバーを実行する

7. 失敗したトランザクションの補正

分散トランザクションを避け、個別のトランザクションで構成し、失敗時には補正トランザクションで元に戻す。

AWS サービス例
  • AWS Step Functions:
    分散トランザクションの各ステップを管理し、失敗時には補償アクションを実行する

8. 実行時間の長いトランザクションにチェックポイントを設ける

長時間の操作が失敗した場合、チェックポイントから再開できるように設計します。

AWS サービス例

9. 障害時の機能低下

完全な停止を避け、制限された機能でも提供し続けることで、ユーザーへの影響を最小限に抑える。

例:

  • Graceful Degradation の設計:
    重要度の低い機能を一時的に停止し、コア機能の提供を継続することで、ユーザーへの影響を最小限に抑える

10. クライアントの制限と問題のあるユーザーのブロック

過度の負荷をかけるユーザーを一時的に制限し、継続的に問題を起こすユーザーはブロックすることで、全体の可用性を維持する。

AWS サービス例
  • AWS WAF:
    特定の IP アドレスやリクエストパターンに基づいて、悪意のあるトラフィックをブロックする
  • Amazon API Gateway:
    スロットリング設定を行い、過剰なリクエストを制限する

11. リーダーの選択の使用

タスクの調整役を動的に選出し、単一障害点を排除する。

AWS サービス例
  • Amazon DynamoDB と Amazon ElastiCache:
    分散システム内でリーダー選出を行う際に、これらのサービスを使用してリーダー情報を管理する

12. フォールト挿入によるテスト

意図的に障害を発生させ、システムの回復性を検証する。

AWS サービス例
  • AWS Fault Injection Simulator:
    意図的に障害を発生させ、システムの耐障害性を検証する

13. アベイラビリティゾーンの活用

アベイラビリティゾーンを利用して、デプロイメントの冗長性と高可用性を確保する。

AWS サービス例
  • マルチ AZ 配置:
    Amazon EC2、Amazon RDS、Amazon S3 などのサービスでマルチ AZ 配置を行い、障害時にもサービスの継続性を確保する
0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?