カテゴリー: AWS

はじめに

Amazon Elastic Container Service (Amazon ECS) でコンテナアプリケーションを運用する際、新しいバージョンのアプリケーションをどのように無停止・安全にリリース（デプロイ）するかは非常に重要な設計ポイントです。

この記事では、デプロイ方法の分類と概要、シナリオを説明していきます。

デプロイ方法の体系

ECSのデプロイ方法は以下のように分類ができます。

1. ローリングデプロイ（ECSの標準デプロイ）
2. ブルーグリーンデプロイ（AWS CodeDeployを使用する方法）
   • 2-1. 一括デプロイ（All-at-once）
   • 2-2. カナリアデプロイ（canary）
   • 2-3. 線形デプロイ（Linear）

以下の章で、それぞれのデプロイ方法について解説をしていきます。

デプロイ方法の詳細

ローリングデプロイ（ECSの標準デプロイ）

概要

ローリングデプロイは、AWS CodeDeploy を使用せず ECS 単体の機能として実行される標準的なデプロイ方式です。

同じ環境内で、新しいバージョンのタスク（コンテナ）を順次立ち上げ、正常起動（ヘルスチェック通過）を確認しながら古いバージョンのタスクを段階的に停止・入れ替えていきます。

メリットとデメリット

メリット

• 追加リソースコストが最小限: サービスの「最小ヘルシー率」「最大率」パラメータの設定に基づき、最小限の追加タスク数で安全に入れ替えを行うため、コスト効率に優れています。
• 構成がシンプル: ロードバランサーの複雑な設定や CodeDeploy 用の設定ファイル（AppSpec 等）を別途用意する必要がなく、手軽に導入可能です。

デメリット

• 新旧バージョンが一時的に混在する: デプロイ実行中の数分間は、旧バージョンのタスクと新バージョンのタスクが同時にトラフィックを受け付けるため、新旧アプリの混在が発生します。
• ロールバックに時間がかかる: 途中でエラーが発生した場合、再度ローリング処理を通して古いタスクを順次起動し直すため、切り戻し完了までに時間がかかります。

2. ブルーグリーンデプロイ

概要

ブルー/グリーンデプロイは、旧バージョン（ブルー環境）と新バージョン（グリーン環境）の 2 つのタスクセットを一時的に並行稼働させ、Application Load Balancer (ALB) や Network Load Balancer (NLB) のルーティングを切り替えることで安全に移行する方式の総称です。

トラフィックのシフト（移行）方法に応じて、以下の 3 つの戦略を選択できます。

2-1. 一括デプロイ（All-at-once）

概要

新環境（グリーン）のタスクセットを 100% 立ち上げて準備を完了させた後、すべてのトラフィック（100%）を一瞬で新しいタスクセットへ一括切り替えします。

メリットとデメリット

メリット

• 新旧バージョンが混在しない: トラフィックが切り替わった瞬間に全員が新環境へ移行するため、新旧混在による不具合が起きません。
• 超高速ロールバック: 万が一不具合が発生しても、ロードバランサーの参照先を旧環境へ戻すだけで即座に復旧できます。

デメリット

• コスト増: 一時的に旧環境と新環境の両方で 100% のタスクを起動するため、2 倍のリソースコストがかかります。
• 影響範囲の大きさ: また、バグがあった場合に全ユーザーへ一括で影響が及びます。

2-2. カナリアデプロイ（canary）

概要

最初に少量のトラフィック（例: 10%）だけを新環境に切り替えて一定時間（例: 5分や15分）様子見（検証）し、問題がなければ残りのトラフィック（90%）を一気に移行します

メリットとデメリット

メリット

• 問題があった場合の被害の最小化: 万が一新バージョンに致命的なバグがあっても、影響を受けるユーザーを最初の少量（10% 等）のユーザーだけに限定可能。

デメリット

• デプロイ時間増: 移行完了までに一定の観察時間（待機時間）が必要です。

2-3. 線形デプロイ（Linear）

概要

指定した時間間隔ごとに、均等な割合（例: 1分ごとに 10% ずつ、または 5分ごとに 25% ずつ）で段階的に新環境へのトラフィックを増やしていく方式です。

メリットとデメリット

メリット

• 負荷のウォッチが可能: トラフィックをなだらかにシフトさせるため、新環境への急激な負荷増大を防ぎつつ、各段階でエラー（CloudWatch アラーム等）を検知した際に自動ロールバックを実行できます

デメリット

• デプロイ時間増: 0% から 100% までの完全移行完了までに最も時間がかかります。

はじめに

AWSでアプリケーションを構築する際、データベースの接続パスワードや外部APIのアクセストークン、環境変数などのパラメータ情報をAWS Secrets Manager と AWS Systems Manager Parameter Store のどちらに保存すべきか？で迷うことがあります。

この記事では、両者の違いやそれぞれの特性（コスト、ローテーション、暗号化、権限制御）を比較し、実際の現場や用途に応じた使い分けのポイントについて理解を深めていきます。

「AWS Secrets Manager」と「AWS Parameter Store」の比較

【ざっくりと理解】AWS CodePipelineとは？

AWS CodePipelineは、ビルド、デプロイ、テストなどの一連の流れを自動化するためのCI/CDサービスです。

CI/CD: 継続的インテグレーション、継続的デプロイ

基本的な概念

利用にあたって押さえておくべき主要な概念は以下の通り

• ステージ(Stage): プロセスを論理的なフェーズ（段階）ごとに区切るための構成単位。
• トランジション（Transition）: ステージとステージの間に存在する接続リンク。
• アクショングループ（Action group）: 非同期で実行されるアクションの単位です。
• アクション（Action）: 具体的な処理内容です。

概念の詳細な説明

それぞれの概念について深堀りをしていきます。

ステージについて

ステージは、CodePiplelineを定義するうえで最も大きな単位になります。

あるステージ内のアクションがすべて成功すると、成果物（リビジョン）が次のステージへ引き渡されて処理が進行します。

• Source ステージ: ソースコードやコンテナイメージの取得
• Build ステージ: コンパイル、静的解析、Docker イメージのビルド
• Test ステージ: 自動テストの実行
• Deploy ステージ: ターゲット環境（Staging / Production 等）へのデプロイ

トランジションについて

各ステージが完了した際に、デフォルトだと次のステージに移行します。
これが「トランジション」です。
トランジションを「無効化」することで、次のステージへの移行を止めることができます。

手動による承認が必要な場合には、「手動承認アクション」を使用することでより詳細にPipelineを管理することができます。

アクショングループ

アクショングループとは、後述のactionのグループです。
runOrderが同一のactionが同一action groupと見なされます。

並列化稼働が必要なactionは同一action groupで定義しましょう。

アクション

具体的な処理内容です。下記の項目で構成されます。

actions:
  - name: RunUnitTest               # アクション名
    actionTypeId:                   # アクション種別識別子
      category: Test                # カテゴリ
      owner: AWS                    # オーナー
      provider: CodeBuild           # プロバイダー
      version: '1'                  # バージョン
    runOrder: 1                     # 実行順序（アクショングループ）（前述）
    inputArtifacts:                 # 入力アーティファクト 
      - name: SourceArtifact
    outputArtifacts:                # 出力アーティファクト 
      - name: TestOutputArtifact
    configuration:                  # プロバイダー固有設定 
      ProjectName: MyUnitTestProject
    region: ap-northeast-1          # リージョン 
    roleArn: arn:aws:iam::123456789012:role/MyActionRole # ロールARN 
    namespace: TestVariables        # 変数用名前空間 

むすび

【ざっくりと理解】AWS CodeArtifact とは？

AWS CodeArtifact は、ソフトウェアパッケージを安全に保存・共有するためのフルマネージド型のアーティファクトリポジトリサービス。

アーティファクトリポジトリ: ビルドされたバイナリファイルを保存するためのリポジトリ

yumやpipなどのライブラリをイメージすれば良さそう。

基本的な概念

利用にあたって押さえておくべき主要な概念は以下の2つ

• ドメイン（Domain）: 組織内でリポジトリ群を一元管理する最上位の管理単位です。通常、1つの組織に対して1つのドメインを作成します。
• リポジトリ（Repository）: パッケージを実際に保管する場所。

pip / twine を使った具体的な手順

ここからは、AWS CLI を使用して環境を構築し、Python パッケージを公開・インストールする具体的な手順です。

aws codeartifact create-domain \
    --domain my-domain

aws codeartifact create-repository \
    --domain my-company-domain \
    --repository my-python-repo

aws codeartifact login \
    --tool pip \
    --domain my-company-domain \
    --domain-owner <AWSアカウントID> \
    --repository my-python-repo

aws codeartifact login \
    --tool twine \
    --domain my-company-domain \
    --domain-owner <AWSアカウントID> \
    --repository my-python-repo

# パッケージのビルド（dist/ 配下に wheel / sdist を生成）
python -m build

# CodeArtifact リポジトリへアップロード
twine upload --repository codeartifact dist/*

pip install my-shared-library

buildspec.ymlとAppSpec.ymlの概要と役割の違い

buildspec.yml

主なセクションの書式

phasesセクションの書式

サンプル

Amazon ECR への Docker イメージのビルド＆プッシュ、および Amazon ECS デプロイに必要な imagedefinitions.json を生成するサンプルコードです

# versionセクション
version: 0.2

# envセクション
env:
  variables:
    # プレーンテキストの環境変数を指定
    AWS_DEFAULT_REGION: "ap-northeast-1"
    IMAGE_REPO_NAME: "my-web-app"

# phasesセクション
phases:
  # 1. install フェーズ: 依存パッケージやビルドツールのセットアップ   install:
    commands:
      - echo "インフラ・ビルドツールの初期化処理を開始します..."

  # 2. pre_build フェーズ: ビルド実行前の準備作業（例: ECRへのログインなど）
  pre_build:
    commands:
      - echo "Amazon ECR 認証トークンの取得とログインを実行中..." 
      # AWS CLI を使用して ECR ログイン用パスワードを取得し docker login を実行
      - aws ecr get-login-password --region $AWS_DEFAULT_REGION | docker login --username AWS --password-stdin $ECR_REGISTRY

  # 3. build フェーズ: アプリケーションのコンパイルや Docker イメージのビルド
  build:
    commands:
      - echo "Docker イメージのビルドを開始..."
      # カレントディレクトリの Dockerfile からイメージをビルドし、タグを付与
      - docker build -t $ECR_REGISTRY/$IMAGE_REPO_NAME:$IMAGE_TAG .

  # 4. post_build フェーズ: ビルド後の処理（ECRへのプッシュや成果物ファイルの生成）
  post_build:
    commands:
      - echo "ビルドした Docker イメージを ECR にプッシュ中..." 
      - docker push $ECR_REGISTRY/$IMAGE_REPO_NAME:$IMAGE_TAG
      - echo "ECS デプロイに必要な imagedefinitions.json を作成中..." 
      # CodePipeline/CodeDeploy へ引き渡すイメージ定義 JSON ファイルを出力
      - printf '[{"name":"web-container","imageUri":"%s"}]' $ECR_REGISTRY/$IMAGE_REPO_NAME:$IMAGE_TAG > imagedefinitions.json

# 後続のデプロイステージへ引き渡すビルド成果物（アーティファクト）の定義
artifacts:
  files:
    # 生成された imagedefinitions.json を成果物として指定
    - imagedefinitions.json

appspec.yml

主なセクションの書式

Resorceセクションの書式

Resorceセクションの書式

サンプル

Amazon ECR への Docker イメージのビルド＆プッシュ、および Amazon ECS デプロイに必要な imagedefinitions.json を生成するサンプルコードです

# versionセクション
version: 0.0

# Resourcesセクション
Resources:
    # ECSが対象サービス
  - TargetService:
      Type: AWS::ECS::Service
      Properties:
        # デプロイで使用する ECS タスク定義の ARN を指定
        TaskDefinition: "arn:aws:ecs:ap-northeast-1:123456789012:task-definition/my-app:1"
        # ロードバランサーがトラフィックを転送するコンテナ情報
        LoadBalancerInfo:
          # タスク定義内で設定されているコンテナ名を指定
          ContainerName: "web-container"
          # コンテナ側で解放されているポート番号を指定
          ContainerPort: 80

# Hooksセクション
Hooks:
  # 本番トラフィック切り替え完了後 (AfterAllowTraffic) に呼び出す Lambda 関数の ARN を指定
  - AfterAllowTraffic: "arn:aws:lambda:ap-northeast-1:123456789012:function:AfterAllowTrafficValidation"