AWS Elastic Beanstalk(1)Elastic Beanstalkの概要

Elastic Beanstalkとは

Elastic Beanstalkは、Java、.NET、PHP、Node.js、Python、Ruby、Go などを使用して開発されたプログラムをApache、Nginx、Passenger、IIS など使い慣れたサーバーでデプロイおよびスケーリングするためのサービス。インフラストラクチャの準備、運営から、アプリケーションスタック (プラットフォーム) の管理までをElastic Beanstalkが担当するため、ネットワーク設定や保守などの作業が不要

All at Onceローリング追加バッチとローリングイミュータブルブルー/グリーンなどの複数のポリシーからデプロイ方法を選択可能である。

Elastic Beanstalkを使用するにあたっての利用料金は不要で、デプロイしたAWSリソースに対する通常の使用料金のみ課金される。

使用するAWSリソースとその機能について、十分な知識を有する場合は、CloudFormationテンプレートを作成して運用することが望ましい。

Elastic Beanstalkのワークフロー

Elastic Beanstalkは、複数のアプリケーションを作成することが可能で、各アプリケーションは、Application VersionEnvironment(デプロイ済みのアプリケーション)やEnvironment TierEnvironmentの種別)、Environment Configuration(Environmentの設定)を有する。

Application Version

デプロイ可能なコードを指し、S3上でバージョン管理される。

Environment Tier

HTTP リクエストを処理し、ウェブアプリケーションを実行可能なWebサーバ環境と、Amazon SQSキューからタスクを引き出し、バッチ処理などをスケーラブルに実行可能なワーカー環境の2つから選択することが可能である。

Webサーバ環境

Webサーバ環境で構築されるEC2のソフトウェアスタックは、選択したコンテナタイプ(テンプレート)によって異なる。また、ホストマネージャー(HM)と呼ばれるソフトウェアコンポーネントも実行され、アプリケーションのデプロイの実行や、アプリケーションの監視等も行なっている。

Webサーバ環境

ワーカー環境

完了するまでに長い時間がかかる処理は、SQSを用いたワーカー環境で実行することが望ましい。ワーカー環境では、Amazon SQS キューを管理しタスクを実行するSQSデーモンが実行される。また、cron.yamlにタスクを記述することで、タスクの定期実行を行うことも可能である。

ワーカー環境

設計上の注意事項

スケーラビリティを確保する方法として、スケールアップ(垂直スケーリング)とスケールアウト(水平スケーリング)が存在が、スケールアップは過剰なリソースの準備となるなど問題点が存在するため、Elastic Beanstalkアプリケーションは、必要に応じてスケールアウトできる耐障害性に優れた疎結合コンポーネントを使用して、できるだけステートレスにする必要がある。

また、耐障害性を有するように、必ず故障から自動回復できるように設計、実装、およびデプロイする必要がある。

アプリケーションの管理

ソースコードをアップロードするたびに、新たなバージョンラベルを付与し、アプリケーションバージョンを作成する。古いアプリケーションバージョンは削除することも可能で、削除してもデプロイ済みのEnvironmentには影響を与えない

アプリケーションバージョンライフサイクルポリシーを設定することで、過去のバージョンを自動的に削除することが可能である。保有するバージョンの数、もしくは期間を設定でき、これを超えるとサービスが自動でアプリケーションバージョンを削除する。

アプリケーションは、ソースバンドルと呼ばれる処理プログラムを含む必要があり、ソースバンドルは、単一のZIPファイルまたはWARファイルで構成される必要がある。AWS Toolkit for Eclipse等を使用して開発を行なっている場合は、ツールが正しく構造化した上でZIP化してくれる。

Environmentの管理

1つのアプリケーションは、開発環境、統合環境、本番環境など複数のEnvironmentをデプロイすることができる。新たなEnvironmentを作成する場合は、

  • プラットフォーム
  • Application Version もしくは 新たなソースバンドル
  • Environment Tier(ウェブ環境/ワーカー環境)

等を指定する。作成したEnvironmentを終了すると、デプロイしたリソースの全てが削除される。

デプロイ

Environmentをデプロイする際には、複数のデプロイ方法の中から1つを選択することが可能である。

方法 デプロイメントポリシー 内容 制約 時間 ダウンタイム DNS変更
All at Once All at Once 現行のインスタンス全てに新たなコードを適用する
Rolling Rolling 現行のインスタンスに順に新たなコードを適用する 単一インスタンス環境では選択できない やや速
Rolling with additional batch Rolling with additional batch 新たなインスタンスと現行のインスタンスの一部に新たなコードを適用する 単一インスタンス環境では選択できない
Immutable Immutable 新たなインスタンスに新たなコードを適用する
Blue/Green Rolling with additional batch もしくは Immutable 新たなインスタンス(と現行のインスタンスの一部)に新たなコードを適用する 単一インスタンス環境では選択できない URL Swap もしくは DNS切り替え

Rollingを用いてデプロイする場合は、更新するバッチサイズを指定する。また、Route53の加重ラウンドロビンを利用することで、新バージョンを徐々に適用していくことも可能である。

プラットフォームの更新

アプリケーションを実行しているプラットフォームの更新を定期的に、もしくは手動で行うことが可能である。また、マイナーアップデートを含めるのか、パッチの適用だけなのかについても選択することができる。

AWS認定(2)デベロッパー(アソシエイト)に合格するまで

AWS認定デベロッパー試験合格に向けての資料集。以下の資料を何度も読み込んで、手を動かしながら実践を繰り返すことが合格の近道となる。

出題範囲と学習法

AWS認定デベロッパー試験の問題は、システムを構築する際に、可用性や拡張性コストなどを考慮した上で、実際どのような手法で実装するかについて問われることが多い。AWSが提供するサービスは100を超えるが、本試験を受講する上では、API Gateway, Cognito, DynamoDB, S3, SQS, IAM(STS), Elastic Beanstalk, Elastic Beanstalk, Lambdaなどのデプロイツールやサーバレスアーキテクチャの理解。また、CloudFormation, CodeBuild, CodeCommit, CodeDeploy, CodePipeline, CloudFront, CloudWatch, ElastiCache, Kinesis, RDS, X-Rayなども理解しておくことが必要である。

勉強法は、

  1. サンプル問題集に目を通してレベルを確認する
  2. 以下の資料を読みながら実際に各サービスに触れる
  3. 模擬試験を受講する

で十分合格ラインに行くかと。ちなみに学習時間は2週間ほど。なお、各サービスのドキュメントにベストプラクティスの項目が存在する場合は、該当部分を理解しておく

対策本

対策本はほとんど発売されていない。以下の本が唯一の試験対策本。この本には、各サービスの概要や特徴が簡潔に書かれており、AWSの各サービスの概要を学ぶためには非常に有効。一方で、章末問題と実際の試験問題は異なるので、実際の問題に慣れるためには、模擬試験の受講が必要である。

AWSの概要とセキュリティ

AWS(1)AWSの概要とメリット
AWS(4)Well-Architectedフレームワーク
AWS(5)セキュリティのベストプラクティス

AWS Identity and Access Management

AWS(2)セキュリティの概要
AWS Identity and Access Management(1)IAMの概要
AWS Identity and Access Management(4)STS

AWSの基本サービスの概要

Amazon S3

AWS S3(3)S3の概要
AWS S3(4)使用する上で注意すること

Amazon RDS

AWS RDS(1)Relational Database Serviceの概要

Amazon DynamoDB

AWS DynamoDB(1)DynamoDBの概要

Amazon ElastiCache

AWS ElastiCache(1)ElastiCacheの概要

AWS Lambda

AWS Lambda(1)Lambdaの概要
AWS Lambda(3)使用する上で注意すること

Amazon Kinesis Data Streams

AWS Kinesis(1)Kinesisの概要

Amazon SQS

AWS SQS(1)Amazon Simple Queue Serviceの概要

AWS Elastic Beanstalk

AWS Elastic Beanstalk(1)Elastic Beanstalkの概要

Amazon CloudWatch

AWS CloudWatch(1)CloudWatchの概要

Amazon SNS

AWS SNS(1)Simple Notification Serviceの概要
AWS SNS(2)モバイルプッシュ通知

Amazon Cognito

AWS Cognito(1)Cognitoの概要

AWS API Gateway(3)カスタムログの出力


API Gatewayは、詳細のアクセスログをCloudWatch Logsに吐き出すことができる。CloudWatch Logsへのログ書き込みを行うためには、書き込み権限の取得とログを書き込むロググループの指定が必要となる。

IAMロールの指定

IAM上でAPI GatewayからCloudWatch Logsへの書き込み許可を持つIAMロールを作成する。IAMでは、あらかじめAmazonAPIGatewayPushToCloudWatchLogsと呼ばれるポリシーが用意されているため、このポリシーがアタッチされたIAMロールを作成する。この作成したIAMロールをAPI Gatewayの設定画面上で指定することで、API GatewayはCloudWatch Logsへの書き込み権限を取得する。

ログの指定

次にAPI Gateway上の各APIのログ/トレース設定画面にて、カスタムアクセスのログ記録を有効化する。入力項目は、CloudWatchロググループのARNと、ログ形式の2種類。ログ形式は、JSONやCLFなどの中から選ぶと自動的に入力される。

AWS API Gateway(2)Kinesisへのデータ投入

API Gatewayから大量のデータを投入し、これらのデータを解析および蓄積する場合には、API GatewayからLambdaに直接データを渡すのではなく、大規模データストリームサービスのKinesisを介した方が、バックエンドのシステムが高負荷に晒されずに安定的に稼働させられる場合がある。

API Gatewayとバックエンドのエンドポイントとの接続は、API Gateway内の統合リクエスト機能を用いて行い、統合リクエストは下の5つの統合タイプを用意している。

  • Lambda関数
  • HTTP
  • Mock
  • AWSサービス
  • VPCリンク

Mockは、バックエンドと接続せずにレスポンスを返す統合タイプで、テストを行う際や、CROSのプリフライトリクエストの返答などに用いる。

統合リクエスト

Kinesisと接続する場合は、POSTメソッドを作成し、上記のうちの「AWSサービス」を選択して以下のように各欄に必要事項を入力する。Kinesisへデータ投入する際には、Kinesis側で用意されているputRecordメソッドを使用する。

データ入力項目

項目 入力内容 備考
統合タイプ AWSサービス
AWS リージョン 当該Kinesisのリージョン
AWS サービス Kinesis
AWS サブドメイン 空欄
HTTP メソッド POST
アクション PutRecord
実行ロール KinesisへのputRecordをAPI Gatewayに許可するIAMロール arn:aws:iam::account-id:role/iam-role-name

IAMロールについては、KinesisへのputRecordをAPI Gatewayに許可する記述が必要で、IAM上で以下の内容を含んだIAMロールを作成する。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
                "kinesis:PutRecord",
                "kinesis:PutRecords"
            ],
            "Resource": "arn:aws:kinesis:*:*:stream/*"
        }
    ]
}

データマッピング

API GatewayからKinesisにデータを投入する場合は、クライアントから受信したデータをKinesisが規定するデータフォマットに変換する必要がある。これに対応するのがデータマッピング機能で、Velocity Template Languageを用いて記述することができる。

よく使われる関数および使用例を以下に挙げる。

記述 内容
#set($param = ”) 変数の定義
#if(評価式) #end if文
$context.requestTimeEpoch データの受信時刻
$input.path(‘$.param’) 入力データ内の指定タグの値
$input.path(‘$.param’).size 入力データ内の指定タグの数
$input.params().header.get(”) ヘッダ内の指定タグの値
$input.json(‘$.param’) 入力データ内の指定タグJSONデータ
$util.urlDecode($input.path(‘$’)) 入力データをURLデコード
$util.escapeJavaScript(data) 文字をエスケープ
$util.base64Encode(data) 文字をBASE64エンコード

また、これらを使用してデータマッピングを記述すると以下となる。

#set($allParams = $input.params())
{
  "params" : {
    #foreach($type in $allParams.keySet())
    #set($params = $allParams.get($type))
    "$type" : {
      #foreach($paramName in $params.keySet())
      "$paramName" : "$util.escapeJavaScript($params.get($paramName))"
      #if($foreach.hasNext),#end
      #end
    }
    #if($foreach.hasNext),#end
    #end
  }
}

AWS API Gateway(1)API Gatewayの概要

API Gatewayとは

API Gatewayは、完全マネージドのAPI作成サービス。受信したAPIコールと送出したデータ量に対して課金される。スロットリングによるトラフィック管理ができるため、DDoSやトラフィックの激増にも対応することが可能であり、リミットを超えたリクエストにはHTTPステータス 429が返却される。また、レスポンスはキャッシュ可能であり、レイテンシやトラフィック等を低減することができる。

API Gatewayは、IAMやCognitoを用いたアクセス認証署名付きAPIコールなどを使用することができるために柔軟にセキュリティ管理ができる。また、CloudWatchやCloudWatch Logsを用いた監視が可能で効率的なデバッグとモニタリングを実現している。

![API Gateway]https://docs.aws.amazon.com/ja_jp/apigateway/latest/developerguide/images/BackplaneArch.png

エンドポイント

API Gatewayは、特定のリージョンにデプロイされる。エンドポイントは以下の3種類がサポートされている。エンドポイントは、HTTPSのみサポートされている。

種類 内容
エッジ最適化 CloudFrontネットワークにデプロイ
リージョン リージョンにデプロイ。EC2 インスタンスまたは API と同じリージョン内のサービスから送られる場合に使用すると良い。
プライベート VPCからのみアクセス可能

リソースとメソッド

APIは階層構造となっており、リソースやメソッドをネストすることも可能。指定可能なメソッドは以下の通り。

種類 実行内容
POST 子リリースの作成
PUT 既存リソースの更新
DELETE リソースの削除
PATCH リソースの更新
HEAD テストシナリオに使用
OPTIONS 通信オプションに関する情報を取得する度に使用できる

CROSを有効にするためには、OPTIONSメソッドのプリフライトリクエストに対してAPIが応答することが必要であり、このリクエストに対して、HTTPステータス 200Access-Control-Allow-Method, Access-Control-Allow-Headers, Access-Control-Max-Ageヘッダを含んだレスポンスを返す。これらの挙動には、統合リクエスト/レスポンスのMockタイプを使用する。

リクエストに対して、 URLクエリ文字列パラメータHTTPヘッダHTTPボディを検証し、必須の項目が含まれているかやキャッシュを行うかなどを指定することができる。HTTPボディがapplication/json形式である場合は、JSON Schemaを用いてJSON形式を指定することもできる。

統合リクエスト/レスポンスとマッピングテンプレート

API Gatewayとバックエンドとを接続する内部インタフェース。マッピングテンプレートを用いることで、フロントエンド(API Gateway)とバックエンドのデータ形式を変換することができる。

  • Lambda関数の呼び出し
  • 他のAWSサービスの呼び出し
  • HTTPウェブサイトのアクセス

の3つのバックエンドへのアクセスに対応している。Lambdaプロキシ統合を用いることで、API GatewayとLambdaがより協力に結合され、リクエストヘッダやパス変数などがLambdaに渡される。また、HTTPプロキシとして使用することも可能である。

デプロイ

APIを利用可能とするためには、APIのリソースおよびメソッドのスナップショットであるAPIのデプロイを実施する必要がある。APIをバージョン管理できるために、新しいバージョンを簡単にテストしリリースすることが可能である。

1アカウント1リージョンあたりのAPIの上限は、10000RPSである。これ以上のアクセス負荷にも耐えうる値とする場合は上限緩和申請が必要となる。

AWS(4)Well-Architectedフレームワーク

Well-Architected Framework

AWS Well-Architected フレームワークは、以下の5つの評価項目で構成されている。

  • 必要なキャパシティを勘に頼らない
  • 本番規模でシステムをテスト
  • 自動化
  • 発展的なアーキテクチャを受け入れる
    • クラウドは自動化とテストが容易で設計変更のリスクを低減できる
    • システムを継続して進化させる
  • データ計測に基づいてアーキテクチャを決定する
  • 本番で想定されるトラブルをあらかじめテストする

1. 運用上の優秀性

設計の原則

  • 運用のコード化を行う
  • ドキュメントに注釈を付ける
  • 頻繁に小さく可逆的な変更を行う
    • システムを小さく設計
    • 失敗した場合に戻せるように
  • 運用手順を頻繁に見直す
  • 発生しうる障害を予想する
  • 運用の失敗を改善に役立てる

ベストプラクティス

準備(本番環境への移行)

  • チェックリストによる検証
  • イベントと障害に対するテスト
  • CloudFormationの利用
  • CloudWatch等を利用した解析
  1. 運用の優先順位を決定する要因は明確ですか?
    • リスクを評価して優先事項を決定することが重要である。
    • ビジネスニーズを評価する
      • 運用事項の決定には、ビジネスチームと開発チームの両方が参加する
    • コンプライアンス要件を評価する
      • 規制や業界標準のルールを考慮する
  2. 運用性を向上させるワークロード設計をしていますか?
    • 設計標準を共有する
      • システム設計に共通の設計標準を取り入れることで複雑性を軽減する
      • 設計標準に対する変更や追加をリクエストする手順を作成し継続的に改善する
    • クラウド運用に向けて設計する
      • 伸縮性や従量課金制などのクラウドの特徴を活用して迅速な改善やテストなどの運用を実現する
    • ワークロードの動作を深く理解する
      • 計測ツールを用いてシステムで何が起こっているかを計測する
    • 顧客の行動を深く理解する
      • 計測ツールを用いてシステムの使用状況を計測する
    • 障害を軽減しフローを改善するための手法を確立する
      • フローを改善して品質向上やバグ修正を迅速に行えるアプローチを確立する
    • デプロイのリスクを軽減する
      • 頻度の高い変更、自動デプロイ、テスト、カナリアデプロイワンボックスデプロイブルーグリーンなどの手法を導入する
  3. ワークロードが運用可能であることをどのように確認していますか?
    • 継続的改善の文化を育てる
    • ビジネスに対する価値の理解を共有する
      • ビジネスにとってシステムがどの程度重要であるのかをチーム全体で共有する
      • 運用上の問題に対応するために必要なリソースを全てのチームが活用できる環境の提供
    • 担当者の能力を確保
      • トレーニングを受けた担当者を適切な人数配置する
    • ガバナンスとガイダンスを文書化し共有する
      • コンプライアンスについて理解しやすく評価可能な標準ルールを共有する
      • 標準ルールの変更、追加をリクエストする手順を作成する
    • チェックリストを使用する
    • 運用手順書ランブック)を使用する
    • 障害対応手順書プレイブック)を使用する
    • 復旧演習を行う

運用

期待されている成果、およびその測定方法を決定し、システムと運用に関する測定基準(メトリクス)を特定する。システムとそのシステムに対する運用の正常性の双方を考慮する。イベント対応の優先度を定めて、影響の度合いに応じて追加の担当者を巻き込むエスカレーショントリガーも含める。計画外のイベントが発生した原因と影響範囲を確認し、今後の運用に反映させるとともに、計画外のイベントであっても自動的に処理されるようにシステムの設計を行う。デプロイやリリース管理、変更ロールバックなどはマニュアルで行なってはならない

  1. 運用状態をどのように確認していますか?
    • ビジネスと顧客について求められる成果を定義する
      • 成功とはどのようなことを指すのか定義し文書化する
    • 成功のメトリクスを特定し達成されているかどうかを確認する
    • ワークロードのメトリクスを特定し達成されているかどうかを確認する
    • 運用のメトリクスを特定し達成されているかどうかを確認する
    • 基準値を定める
    • メトリクスを収集および分析する
    • 分析結果をレビューし対応を確認する
    • 運用のビジネスレベルレビュー
      • ビジネスの目標を達成するために改善が必要な分野を特定する
  2. 運用上のイベントをどのように管理していますか?
    • ビジネスへの影響に基づいて運用イベントの優先順位を決定する
    • イベントやインシデントを管理する方法を確立する
    • アラートを設定したイベントごとの運用手順書(ランブック)を確立する
    • 意思決定者を確立する
    • 障害報告ルートエスカレーションパス)を定義する
    • プッシュ通知
    • ダッシュボードを通じてステータスを通知
    • 根本原因分析のためのプロセスの確立

進化

システムを継続的に少しずつ改善していくことが必要。システムと運用の両方に関して改善できる部分を洗い出し、優先順位を付ける。また、チームを超えて、運用から学んだ知見を共有する。

  1. 運用をどのように進化させていますか?
    • 継続的な改善プロセス
    • 改善の要因の定義
    • フィードバックループを取り入れる
    • 得られた知識を文書化して共有
    • 運用メトリクスの評価を行う

AWSのサービス

AWS CloudFormationを用いてシステム構築を行う。またそれぞれのフェーズで以下のサービスを活用する。

フェーズ AWSサービス 目的
準備 AWS Config システム標準を作成しそれに準拠しているか確認する
運用 Amazon CloudWatch システムの運用状態をモニタリング
進化 Amazon Elasticsearch Service ログデータを分析

2. セキュリティ

設計の原則

  • 強固な認証基盤を整備する
  • 追跡可能性を実現する
  • 全てのレイヤーにセキュリティを適用する
  • セキュリティのベストプラクティスを自動化する
  • 転送中および保管中のデータを保護する
  • データへの直接的なアクセスや手動処理を減らす
  • セキュリティイベントに対して準備を行う

ベストプラクティス

アイデンティティとアクセス管理

権限を持つユーザのみが管理者の意図した方法でリソースにアクセスできるようにする。IAMを用いてきめ細やかなポリシーを適用し、ユーザやグループ、ロール、リソースにアクセス許可を割り当てる。認証情報はシステム間で共有しない。プログラムによるAPIアクセスなどには、STSを用いた一時的な認証情報の利用も検討する。

  1. ワークロードの認証情報をどのように管理していますか?
    • MFAの導入
    • パスワードの要件を決定
    • 認証情報を定期的に更新
    • 認証情報を定期的に監査
    • 一元化されたIDプロバイダーを使用
  2. AWSサービスへの人為的なアクセスをどのように制御していますか?
    • 認証情報を共有しない
    • ユーザのライフサイクルポリシを定義
    • 最小権限を付与
    • アクセス要件を明確に定義
    • ロールやフェデレーションを用いてアクセス権を付与
  3. AWSサービスへのプログラムによるアクセスをどのように制御していますか?
    • 認証情報を共有しない
    • 動的な認証
    • 最小権限を付与
    • アクセス要件を明確に定義

発見的統制

発見的統制には様々な手法があり、アセットとその詳細な属性の一覧を作成し、意思決定やライフサイクル管理を促進することで、運用の基準を確立する手法や、内部監査を使用して、実態がポリシーと一致しているかの確認を行う手法などが存在する。AWSにはこれらを実現するために、Cloud TrailCloudWatchAWS ConfigAWS GuardDutyなどの様々なサービスが提供されている。

またログ管理も非常に重要である。また、潜在的なセキュリティインシデントを特定するためにログを分析することも重要である。

  1. ワークロードのセキュリティイベントをどのように検知していますか?
    • 利用可能なロギングを有効化する
    • AWS CloudTrailを分析する
    • ログを一元的に収集し自動的に分析する
    • 重要なメトリクスとイベントをモニタリングし、アラートを送信する
    • AWS Marketplace や APNパートナーのソリューションを活用する

インフラストラクチャ保護

多層に渡る防御などによって組織や規則上の義務を果たす必要がある。AWSが提供しているサービスやパートナーが提供するサービスを利用して、境界保護の強化、出入口のモニタリング、広範囲のロギング、モニタリング、アラート等を行う必要がある。

  1. ネットワークをどのように保護していますか?
    • VPCを使用してトラフィックを分離・制御する
    • 境界でトラフィックを制御する
    • 利用可能な機能を使用してトラフィックを制御する
      • セキュリティグループ
      • ネットワークACL
      • サブネット
    • AWS Marketplace や APNパートナーのソリューションを活用する
  2. AWSのセキュリティ機能と一般的なセキュリティ脅威に関する最新情報をどのように認識していますか?
    • リリース毎に新しいセキュリティサービスを評価する
    • セキュリティサービスを使用する
  3. コンピューティングリソースをどのように保護していますか?
    • デフォルトの設定を強化する
    • ファイルの整合性を確認する
    • 侵入検知を利用する
    • AWS Marketplace や APNパートナーのソリューションを活用する
    • 設定管理ツールを使用する
    • 定期的パッチ適用脆弱性スキャンを実行する

データ保護

AWSでは、データの暗号化やキーローテーション、ロギング、高い耐久性、バージョニングなどのデータを保護するための様々な機能を提供している。また、保管中と転送中の暗号化を複数の手段で実現できる。

  1. データをどのように分類していますか?
    • データ分類スキーマを使用する
    • データ分類を適用する
  2. データ保護メカニズムをどのように管理していますか?
    • KMSCloudHSMなどのキー管理サービスを使用する
    • サービス内に存在する制御機能を利用する
    • クライアントサイドのキー管理を使用する
    • AWS Marketplace や APNパートナーのソリューションを活用する
  3. 保存中のデータをどのように保護していますか?
    • データの暗号化
  4. 転送中のデータをどのように保護していますか?
    • データの暗号化

インシデント対応

インシデント発生時に、システムの分離影響範囲拡大の抑制通常運用への復帰フォレッジング(証拠保全)などの対応を行うことが可能な体制を確立しておく必要がある。

  1. インシデントに対してどのように備えていますか?
    • セキュリティチームに事前にアクセス件を付与しておく
    • ツールの準備
    • ゲームデーの実施

AWSのサービス

内容 AWSサービス 備考
アクセス管理 IAM リソースへのアクセス管理
発見的統制 CloudTrail APIコールの記録
発見的統制 Config リソース設定インベントリ
発見的統制 Guard Duty 悪意のある動作や不正な動作の検出
発見的統制 CloudWatch リソースのモニタリング
インフラストラクチャの保護 VPC
インフラストラクチャの保護 CloudFront 安全な配信、DDoS攻撃を緩和するSieldとの結合
インフラストラクチャの保護 WAF アプリケーションファイアウォール
データ保護 KMS 暗号化キーの作成と管理
インシデント対応 CloudFormation クリーンルームの作成

3. 信頼性

高い信頼性を維持するためには、システム基盤を十分にモニタリングして、需要や要件の変更を処理するメカニズムを設けることが必要である。具体的には、インフラやサービスの障害からの復旧、必要に応じたリソースの動的な取得、設定ミスや一時的なネットワーク問題などの障害軽減などを検討する必要がある。

設計の原則

  • 復旧手順をテストする
  • 障害から自動的に復旧する
  • 水平方向にスケールして統合的なシステムの可用性を向上させる
  • キャパシティを勘に頼らない
  • 自動化の変更を管理する

ベストプラクティス

基盤

システムのアーキテクチャを設計する前に、信頼性に影響を与える基盤についての要件が整っていることが重要で、AWSの場合はこれらの要件は最初から組み込まれているか、必要に応じて対処できるようになっている。一方で、AWSでは意図せずに過剰にリソースをプロビジョニングしてしまわないように、サービスの上限が設定されている。

  1. AWSサービスの制限をどのように管理していますか?
    • 能動的にモニタリングし制限事項を管理する
    • 制限のモニタリングを自動化する
    • 変更できない制限に注意する
    • フェールオーバに備えて十分余裕をもったリソースを確保しておく
  2. AWS上でのネットワーク構成をどのように設計していますか?
    • オンプレミスと接続しない構成を検討する
    • AWSとオンプレミス間に可溶性の高い接続を実装する
    • 可用性の高いネットワーク接続を実装する
    • 複数のVPCで重複しないプライベートIPアドレス範囲を使用する
    • 拡張性と可用性を考慮してサブネットの割り当てを行う

変更管理

変更がシステムに及ぼす影響を把握し、KPIへの対応を自動化することができる。需要の変更に対応してリソースの追加や削除が自動的に行われるようシステムを設計しておくことで、信頼性が向上しビジネスの成功が運用の負担になることも避けられる。適切にモニタリングされていれば、KPIが予測された基準から逸脱したときにアラートを送ることができる。

  1. システムに対する需要の変化にはどのように対応していますか?
    • 自動的にスケールするワークロードとする
    • 負荷テストを実施する
  2. AWSリソースをどのようにモニタリングしていますか?
    • 全ての階層でモニタリングする
    • モニタリングに基づいて通知を行う
    • イベント発生時にイベントに自動で対応する
    • 定期的にレビューを実施する
  3. 変更をどのように実施していますか?
    • 自動化する

障害管理

障害が発生した場合にそのまま本番環境で診断して修復するのではなく、本番環境外で新しいリソースに置き換えて分析することが重要である。論理エラーと物理エラーの両方から確実に復旧できるように、定期的にデータをバックアップし、バックアップファイルをテストしておく目標復旧時間(RTO)や目標復旧時点(RPO)を定め、システムの回復性を事前に評価する。

  1. データをどのようにバックアップしていますか?
    • 手動のバックアップ
    • 自動化したバックアップ
    • 復旧テストの実施
    • バックアップの暗号化
  2. システムがコンポーネントのエラーに耐えるようにどのように設計していますか?
    • 全ての階層でモニタリングを行いエラーを検知する
    • 複数のAZにデプロイする
    • 疎結合のシステムにする
    • グレースフルデグラデーション
    • 自動機能を使用して修復を行う
    • 可用性に影響するイベント発生時に通知を行う
      • 自動修復された後でも通知を送信する
  3. システムの弾力性をどのようにテストしていますか?
    • 障害対応に備えた障害対応手順書(プレイブック)を用意する
    • 障害注入テストを行う
    • ゲームデーの実施
    • RCA(Root Cause Analysis)の実施
  4. 災害時のリカバリプランはどうなっていますか?
    • 目標復旧時間(RTO)や目標復旧時点(RPO)を定義する
    • 上記を達成するために災害対策(DR)戦略を定義する
    • 本番サイトとDRサイトのずれを管理する
    • DRサイトへのフェイルオーバを定期的にテストする
    • 復旧を自動化する

AWSのサービス

内容 AWSサービス 備考
基盤 IAM リソースへのアクセス管理
基盤 Config リソース設定インベントリ
基盤 Trusted Advisor サービスの制限を把握
基盤 Shield DDoSからの保護
変更管理 CloudTrail APIコールの記録
変更管理 Config リソース設定インベントリ
変更管理 Auto Scaling 需要管理の自動化
変更管理 CloudWatch リソースのモニタリング
障害管理 CloudFormation リソースを規則的にプロビジョニング
障害管理 Glacier 耐久性の高いアーカイブ

4. パフォーマンス効率

需要や技術の進歩に合わせてパフォーマンスを維持することが重要である。

設計の原則

  • 最新テクノロジーの標準化
  • グローバル化を即時に実現
  • サーバレスアーキテクチャの使用
  • 実験の頻度の増加
  • 適合したテクノロジーアプローチ

ベストプラクティス

選択

特定のシステムに最適なソリューションは、ワークロードの種類によって異なり、多くの場合は複数のアプローチを組み合わせたものとなる。複数のソリューションを使用して、様々な機能を有効化することで、パフォーマンスを向上させることができる。アーキテクチャを選択する際には、データ駆動型のアプローチを使用して判断を行う。

  1. 最も良いパフォーマンスのアーキテクチャをどのように選択していますか?
    • テストの結果(ベンチマーク)を元に検討する
    • 負荷テストの結果を元に検討する
  2. コンピューティングソリューションをどのように選択していますか?
    • 複数のサービスの中から検討する
    • インスタンスの設定オプションを検討する
    • コンテナの設定オプションを検討する
    • 関数の設定オプションを検討する
    • 伸縮性を活用する
  3. ストレージソリューションをどのように選択していますか?
    • ストレージ特性を検討する
    • 設定オプションを検討する
    • アクセスパターンを検討する
  4. データベースソリューションをどのように選択していますか?
    • データベース特性を検討する
    • 設定オプションを検討する
    • アクセスパターンを検討する
    • データベース以外の他のアプローチを検討する
  5. ネットワークソリューションをどのように選択していますか?
    • ロケーションを検討する
    • サービスを検討する
    • ネットワーク機能を検討する

レビュー

システム導入から時間が経つと、新しい技術とアプローチが利用できるようになる。AWSの新たなサービスや機能を利用することで、パフォーマンスを大幅に改善できる可能性がある。アーキテクチャのパフォーマンスが何で制約されているかを把握しておくことで、その制約を解決するリリースに気づくことができる

  1. 新しいサービスや機能をどのように取り入れていますか?
    • 評価するプロセスを作成する

モニタリング

システムを実装したらパフォーマンスをモニタリングし、エンドユーザが認識する前に問題を解決する必要がある。モニタリングメトリクスを利用して、閾値を超えたときにアラームを送信するようにする。誤検出が大量に発生していないかや、データを処理しきれなくなっていないかなどを確認する。

  1. 期待通りのパフォーマンスを発揮しているかをどのようにモニタリングしていますか?
    • モニタリング
    • 安全な境界を超えた場合にアラートを送信する
    • 問題の修正を自動化する

トレードオフ

ソリューションを構築する際にトレードオフを考慮することで最適なアプローチを選択できる。トレードオフによりアーキテクチャの複雑さが増す可能性があることに留意する。

  1. パフォーマンスを向上させるためにトレードオフをどのように利用していますか?
    • AWSサービスを利用する
    • パターンを使用する
      • キャッシュ
      • リードレプリカ
      • シャーディング
      • 圧縮
      • バッファリング

AWSのサービス

内容 AWSサービス 備考
レビュー AWSブログ 新しいサービス情報の取得
モニタリング CloudWatch リソースのモニタリング

5. コスト最適化

設計の原則

  • 消費モデルを導入する
  • 全体的な効率を評価する
  • データセンターの運用費を排除する
  • 支出を分析し帰属させる
  • 所有コストを削減するためにマネージドサービスとアプリケーションサービスを利用する

ベストプラクティス

コスト効率に優れたリソース

適切なサービスを用いた優れた設計システムでは、最もコスト効率に優れたリソースが使用されており、優れたコスト効果が得られる

  1. AWSサービス選択の際にコストをどのように評価していますか?
    • サービスを選択する
    • ライセンスコストを最適化する
    • サーバレスとコンテナベースのアプローチを使用する
    • 適切なストレージを使用する
    • 適切なデータベースを使用する
  2. コスト目標を達成するためにインスタンスタイプとサイズをどのように選択していますか?
    • メトリクスに基づいてリソースをサイジングする
  3. コスト削減のために料金モデルをどのように選択していますか?
    • リザーブドインスタンスとリザーブドキャパシティ
    • スポットインスタンス
    • リージョンごとのコスト差を考慮
  4. データ転送料金についてどのように計画していますか?
    • 最適化
    • CDNの利用
    • Direct Connectの利用

需要と供給の一致

需要と供給を最適に一致させることが最もコストが掛からないが、その一方で障害に備えて供給に十分な余力を残しておくことも重要である。AWSでは需要に応じて自動的にリソースをプロビジョニングできる。使用するパターンやプロビジョニングに掛かる時間についてもよく考慮する必要がある。

  1. リソースの供給と顧客の需要をどのように一致させていますか?
    • Autoscalingの利用
    • KinesisやSQSなどのバッファサービスの利用
    • 時間ごとに調整する

費用の把握

それぞれのビジネスオーナまたは製品オーナに属するコストを明確にすることで、リソースを効率的に使用して無駄を削減できる。コストの帰属を明確化することが必要。コスト配分タグを使用してAWS使用料とコストを分類および追跡できる。

  1. AWS使用量とコストをどのようにモニタリングしていますか?
    • リソースのタグ付け
    • Cost Exploerの使用
    • 予算超過の通知
    • ビジネス成果に基づいてコストを配分
  2. AWS使用量をどのように管理していますか?
    • グループとロールを定義
    • プロジェクトのライフサイクルを追跡
  3. 不要なリソースをどのように排除していますか?
    • 削除の自動化
    • 削除プロセスを定義

継続した最適化

AWSによる新たなサービスや機能のリリース時に、既存の決定事項を見直すことで、よりコスト効率のよいシステムとすることができる。定期的にデプロイについてレビューする際には、コストを削減する上でどのサービスが役にたつか評価する

  1. 新しいAWSサービスをどのように評価していますか?
    • 定期的なレビュー
    • コスト最適化を行う担当者を置く
    • ワークロードのレビューと分析
内容 AWSサービス 備考
コスト効率に優れたリソース Cost Explorer リザーブドインスタンス導入
需要と供給の一致 Auto Scaling 需要管理の自動化
費用の把握 Cost Explorer 使用状況の確認および追跡
継続した最適化 AWSブログ 新しいサービス情報の取得

AWS認定(1)ソリューションアーキテクト(アソシエイト)に合格するまで

AWS認定ソリューションアーキテクト試験合格に向けての資料集。以下の資料を何度も読み込んで、手を動かしながら実践を繰り返すことが合格の近道となる。

出題範囲と学習法

AWS認定ソリューションアーキテクト試験の問題は、システムを構築する際に、可用性や拡張性コストなどの観点から、どのAWSサービスをするべきかについて問われることが多い。AWSが提供するサービスは100を超えるが、本試験でよく出題されるサービスは、EC2ELB, Autoscaling, S3(Glacier), EBS, RDS, Cloudfront, SQSなど。

勉強法は、

  1. サンプル問題集に目を通してレベルを確認する
  2. 以下の資料を読みながら実際に各サービスに触れる
  3. 模擬試験を受講する

で十分合格ラインに行くかと。ちなみに学習時間は2週間ほど。

対策本

対策本はほとんど発売されていない。以下の本が唯一の試験対策本。この本には、各サービスの概要や特徴が簡潔に書かれており、AWSの各サービスの概要を学ぶためには非常に有効。一方で、章末問題と実際の試験問題は異なるので、実際の問題に慣れるためには、模擬試験の受講が必要である。

AWSの概要とセキュリティ

AWS(1)AWSの概要とメリット
AWS(4)Well-Architectedフレームワーク
AWS(5)セキュリティのベストプラクティス

AWS Identity and Access Management

AWS(2)セキュリティの概要
AWS Identity and Access Management(1)IAMの概要
AWS Identity and Access Management(4)STS

AWSの基本サービスの概要

Amazon EC2 と Elastic Load Balancing

AWS EC2(1)EC2の概要
AWS EC2(3)AMIとインスタンス
AWS EC2(6)Elastic Load Balancing

Amazon VPC

AWS VPC (1)Amazon Virtual Private Cloud とは

Amazon S3

AWS S3(3)S3の概要
AWS S3(4)使用する上で注意すること

Amazon RDS

AWS RDS(1)Relational Database Serviceの概要

データベース

DynamoDB

AWS DynamoDB(1)DynamoDBの概要

モニタリングと通知

Amazon CloudWatch

AWS CloudWatch(1)CloudWatchの概要

Amazon SNS

AWS SNS(1)Simple Notification Serviceの概要
AWS SNS(2)モバイルプッシュ通知

分析

Amazon Kinesis Data Streams

AWS Kinesis(1)Kinesisの概要

開発者ツール

AWS CLI

AWS CLI(1)初期設定とコマンド例

モバイル

Amazon Cognito

AWS Cognito(1)Cognitoの概要

AWS RDS(1)Relational Database Serviceの概要

RDSとは

RDSは、AWS内でRDBSを簡単に設定、運用、スケールできるサービスで、データベースのセットアップやパッチ適用、バックアップなどの管理タスクを自動化している。対応しているRDBSは、Amazon AuroraMySQLMariaDBOracleMicrosoft SQL ServerPostgreSQLの6種類である。一部制限事項も存在するため、この制限事項とのトレードオフが許容できない場合は、EC2上でRDBSを稼働させることも検討する。

管理負荷を軽減

RDBSにわずか数分でアクセス可能で、CloudWatchによる監視にも対応しているため、パフォーマンスの問題を簡単に検出することが可能である。また、ソフトウェアのパッチが自動的に適用されるために、常に最新の状態が維持されている。

パフォーマンス

汎用(SSD)ストレージプロビジョンドIOPS(SSD)ストレージから選択することが可能である。

スケーラビリティ

最大32vCPUおよびRAM244GiBまで拡張することが可能で、数分以内にスケーリングすることができる。また、ストレージサイズも柔軟に拡大が可能で、稼働中にダウンタイムなしに最大16TBまでストレージの拡張を行うことができる。また、リードレプリカを使用(=Amazon AuroraMySQLMariaDBPostgreSQLのみ対応)することで、読み込み負荷の高い処理をスケールアウトすることができる。

可用性と耐久性

自動バックアップ機能によって自動的(=1日に1回)に、もしくは任意の時点のスナップショットを保存することもでき最大35日(デフォルトは7日間保持)まで保存可能。また、RDは、5分に1回トランザクションログを保存しているため、これを用いて新たなインスタンスを起動(ポイントインタイムディカバリ)が可能。マルチAZ配置オプションを使用することで、異なるAZのスタンバイインスタンスにデータを複製し、可用性を向上させることができ、ハードウェア障害が発生した場合には、自動でフェールオーバされる。DNSでCNAMEが書き換えられ切り替えには数分要する。なお、スナップショット実行時は、短時間I/Oが停止することに注意が必要

セキュリティ

KMSを使用してデータベースを暗号化することが可能。また、VPC上で稼働させることで独自のネットワーク上で外部と隔離された状態で稼働できる。

AWS SNS(2)モバイルプッシュ通知

モバイルプッシュ通知

AWS SNSは、モバイルデバイスのアプリケーションにプッシュ通知メッセージを直接送信できる。通知可能なサービスは、

  • Amazon Device Messaging (ADM)
  • iOS および Mac OS X 用の Apple Push Notification Service (APNS)
  • Baidu Cloud Push (Baidu)
  • Android 用 Google クラウドメッセージング (GCM)
  • Windows Phone 用 Microsoft プッシュ通知サービス (MPNS)
  • Windows プッシュ通知サービス (WNS)

である。

プッシュ通知サービスは、登録時にデバイストークンを返すため、SNSはこのデバイストークンを元にモバイルエンドポイントを作成しプッシュ通知を行う。モバイルプッシュ通知を行うためには以下の手順が必要となる。

  1. 認証情報を上記サービスに対して要求し認証情報を取得する
  2. トークンを上記サービスに対して要求しトークンを取得する
  3. プラットフォームアプリケーションオブジェクトを作成する
  4. プラットフォームエンドポイントオブジェクトを作成する
  5. メッセージを送信する

AWS SNS(1)Simple Notification Serviceの概要

Amazon SNSについて

Amazon SNSは、マネージド型のメッセージ発行/購読サービス。SNSは、発行者からのメッセージを受信し、LambdaやSQS、Email、SMSなどの購読者に対してこれらを送信することが可能である。SNSを使用するときは、その所有者としてトピックを作成し、発行者と購読者を定義するポリシーを策定する。

SNSの流れ

トピック名は他と識別できるユニークな名称であり、発行者はこのARNを利用してメッセージをこのトピックに送信する。購読者は、送信されたメッセージを購読するかどうか判断し、購読を許可した場合に全てのメッセージが受信可能となる。発行者は、各配信先ごとに異なるメッセージを送信することも可能である。トピックの所有者は、購読情報を全て削除(クリーンアップ)することも可能となっている。

SNSの機能とシナリオ

SNSは以下のようなシナリオで動作させることができる。

ファンアウト

発行者からのメッセージをSNSが複製することで、並列非同期処理が可能となるシナリオ。並行処理を行なったり、本番環境のデータをテスト環境に入力するために使用できる。

アラートの送信

アプリケーションやシステムからの出力に対してあらかじめ閾値を定めておき、それを超えた場合にメッセージが送信される。

EメールおよびSMSの送信

特定の購読者へEメールおよびSMSの送信する。

モバイルプッシュ通知

モバイルアプリケーションへ通知を送信する。

ポリシー

所有者は各トピックに対して、「どの購読者(=プリンシパル)がどの配信先(=リソース)を受信できるか。」「どの発行者(=プリンシパル)がメッセージの発行を行えるか」などのアクションを定めることができる。ポリシーのデフォルトは拒否であるため、許可を与えるためにはポリシーを明示しなくてはならない。また、ポリシーでは、リトライ回数や遅延時間等も指定することができる。