1クール続けるブログ

とりあえず1クール続けるエンジニアの備忘録

インフラ初心者がAWS(Amazon ECS)についてまとめてみた

前提となる知識の理解

以下の資料を読んで理解を深めた。
アマゾン ウェブ サービスの概要
20180411 AWS Black Belt Online Seminar Amazon EC2
リージョンとアベイラビリティーゾーン - Amazon Elastic Compute Cloud
AWSにおけるマルチアカウント管理の手法とベストプラクティス
AWS アカウント ID とその別名 - AWS Identity and Access Management
AWS Black Belt Online Seminar AWS Identity and Access Management (AWS…

RegionとAvailability Zone

  • AWS クラウドインフラストラクチャはリージョンとアベイラビリティーゾーン (AZ) を中心として構築される。
  • リージョンは2つ以上のAZ から構成されている(ローカルリージョンを除く)。各リージョンは、他のリージョンと完全に分離されるように設計されている。
  • 各AZは互いに影響にを受けないように、地理的・電源的・ネットワーク的に独立している。AZ間は低遅延の高速専用線で繋がれている。
  • AZ は 1 つ以上の独立したデータセンターで構成される。各データセンターは、冗長性のある電源、ネットワーキング、および接続性を備えており、別々の設備に収容されている。このような AZ によって、お客様は単一のデータセンターでは実現できない高い可用性、耐障害性、および拡張性を備えた本番用のアプリケーションとデータベースを運用できる。
  • AZはAWS上ではリージョンコードとそれに続く文字識別子によって表されます (us-east-1a など)
  • 東京リージョンのリージョンコードはap-northeast-1で大阪ローカルリージョンのリージョンコードはap-northeast-3となっている。

https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/images/aws_regions.png

Account

  • AWSアカウントはAWSアカウントIDによって一意に識別される。全てのAWS製品の中で一意であれば、AWS アカウントの別名を作成することもできる(ただし一つまで)
  • AWSアカウントとは、”リソース管理の単位”かつ”セキュリティ上の境界”であり、”AWS課金単位”でもある。
  • 単一でなく、複数のAWSアカウントの使用がAWSゴールドパートナーであるNRIさんの推奨である。
  • 複数のAWSアカウントを用いる理由(メリット)
    • ガバナンスの観点
      • 本番環境の管理コンソール(後述)を分離できる
      • 本番環境と非本番環境を管理するメンバーとで明確な権限の分離
      • 環境間におけるセキュリティ対策の分離が可能
    • 課金の観点
      • 分離したアカウント毎に明確な課金管理を行うことができる。
      • 複数のコストセンターやLOB等に対し、シンプルな課金やチャージバックの運用を行うことができる。
    • 組織の観点
      • 異なるLOBを異なる課金管理と共にサポートすることができ、LOB単位での管理を容易に行うことができる
      • 統制や課金が異なる専用アカウントを用いる個々の顧客に対してサービスプロバイダー型のサービスを提供しやすい
    • 運用の観点
      • 変更による影響範囲を縮小し、リスクアセスメントをシンプルにできる。例)開発環境の変更が本番環境に及ばない
      • AWSアカウントのリソース上限にかかる可能性を緩和できる

サービスにアクセスする方法

AWS IAM (Identity and Access Management)

  • AWS操作をよりセキュアに⾏うための認証・認可の仕組み
  • AWS利⽤者の認証と、アクセスポリシーを管理
    • AWS操作のためのグループ・ユーザー・ロールの作成が可能
    • グループ、ユーザーごとに、実⾏出来る操作を規定できる
    • ユーザーごとに認証情報の設定が可能 f:id:jrywm121:20180505205648p:plain

AWSアカウント(root)ユーザー

  • AWSアカウント作成時のID
  • アカウントの全ての AWS サービスとリソースへの完全なアクセス権限を持つ
  • アカウントの作成に使⽤したメールアドレスとパスワードでサインイン
  • ⽇常的なタスクには、それが管理者タスクであっても、root ユーザーを使⽤しないことを強く推奨
  • AWSのroot権限が必要な操作
    • AWS ルートアカウントのメールアドレスやパスワードの変更
    • IAMユーザーの課⾦情報へのアクセスに関するactivate/deactivate 等々…
  • AWSルートアカウントはIAMで設定するアクセスポリシーが適⽤されない強⼒なアカウントであるため、⼗分に強度の強いパスワードを設定した上、通常は極⼒利⽤しないような運⽤をする。Security CredentialのページからAccess Keyの削除を行う。

IAMユーザー

  • AWS操作⽤のユーザー(1AWSアカウント毎に5000ユーザーまで作成可能)
  • ユーザーごとにユーザー名/パス(オプション)/所属グループ(上限は10)/パーミッション(Json形式で記述)

IAMグループ

  • IAMユーザーをまとめるグループ(1AWSアカウント毎に100グループまで作成可能)
  • グループ毎にグループ名/パス(オプション)/パーミッション

IAMで使⽤する認証情報

  • アクセスキーID/シークレットアクセスキー(2つまで) = REST,Query形式のAPI利⽤時の認証に使⽤
  • X.509 Certificate = SOAP形式のAPIリクエスト⽤
  • AWSマネジメントコンソールへのログインパスワード
  • 多要素認証(MFA)

アクセス条件の記述

f:id:jrywm121:20180505214653p:plain

AWS CloudTrail

  • AWSアカウントで利⽤されたAPI Callを記録し、S3上にログを保存するサービス。
  • AWSのリソースにどのような操作が加えられたか記録に残す機能であり全リージョンでの有効化を推奨。
  • 適切なユーザーが与えられた権限で環境を操作しているかの確認と記録に使⽤。
  • 記録される情報
    • APIを呼び出した⾝元
    • APIを呼び出した時間
    • API呼び出し元のSource IP
    • 呼び出されたAPI 等々…

IAMロール

  • AWSサービスやアプリケーション等、エンティティに対してAWS操作権限を付与するための仕組み
  • IAMユーザーやグループには紐付かない
  • 設定項⽬は、ロール名とIAMポリシー

AWS STS(Security Token Service)

  • ⼀時的に利⽤するトークンを発⾏するサービス
  • ユーザーに対して、以下の3つのキーを発⾏
    • アクセスキー:(ASIAJTNDEWXXXXXXX)
    • シークレットアクセスキー:(HQUdrMFbMpOHJ3d+Y49SOXXXXXXX)
    • セッショントークン(AQoDYXdzEHQ……1FVkXXXXXXXXXXXXXXXXXXXXXXXX)
  • トークンのタイプにより有効期限は様々

AWSを運用する上での常識を身につける

以下の資料を読んで理解を深めた。 (英語のホワイトペーパーは読めてない)
20180403 AWS White Belt Online Seminar AWS利用開始時に最低限おさえておきたい10のこと
AWS Well-Architected Framework
AWS Black Belt Online Seminar 2016 AWS CloudTrail & AWS Config
Amazon RDS 入門

セキュリティ

  • AWSルートアカウントは極力使用しない
    • 十分に強度の強いパスワードを設定した上で多要素認証(MFA)で保護し、通常は極力使用しない運用を行う。
    • Security CredentialのページからAccess Keyの削除を行う。
  • ユーザには最小限の権限を付与する
    • IAMユーザとIAMグループを利用する
    • 最小限のアクセス権を設定し、必要に応じて追加のアクセス権限を付与する。
    • 特権のあるIAMユーザ(機密性の高いリソースやまたはAPIにアクセスが許されているユーザ)に対してはMFAを設定する
    • 認証情報を定期的にローテーションする
  • 認証情報を埋め込まない
    • 認証情報をOSやアプリケーション側に持たせることなく、IAMロールを使用してAWSサービス操作権限を付与する
    • 認証情報はSTS(Security Token Service)で生成し、自動的に認証情報のローテーションが行われる
  • 証跡取得(ログ取得)
    • AWS CloudTrailによって操作ログを取得する。取得したログをCloudWatch Logsに転送し監視することも可能
    • Amazon GuardDutyを利用して疑わしいアクティビティをログから検知する
  • 各レイヤでのセキュリティ対策
    • ネットワークレイヤ(ネットワークACL
      • VPCのサブネット単位で設定するステートレスなファイアーウォール
      • ベースラインとなるポリシーを設定するのに用いる
    • Amazon RDS / EC2などのリソース(セキュリティグループ)
      • インスタンス(グループ)単位に設定するステートフルなファイアーウォール
      • サーバの機能や用途に応じたルール設定に適している
    • AWS WAF
    • AWS Shield

コスト最適化

  • 適切なサイジング
    • AWS CloudWatchでリソース利用状況を把握する
      • AWS上で稼働するシステム監視サービス
      • システム全体のリソース使用率、アプリケーションパフォーマンスを把握
      • 予め設定した閾値を超えたら、メール通知、AutoScalingなどのアクションを起こすこともできる
      • またCloudWatch LogsでOS上やアプリケーションのログも取得可能

データのバックアップ

  • EC2のAMI(Amazon Machine Image)を作成。
  • EBSのスナップショットを取得。作成時はデータ整合性を保つために静止点を設けることを推奨
  • RDSの自動バックアップ機能

障害や不具合への対策

f:id:jrywm121:20180506011824p:plain

  • ELB(Elastic Load Balancing)の活用
  • AutoScalingの活用
  • EC2 AutoRecoveryの活用

Amazon VPC(Virtual Private Cloud)

以下の資料を読んで理解を深めた。
20180418 AWS Black Belt Online Seminar Amazon VPC
AWS Black Belt Online Seminar 2016 AWS CloudFormation

概要

  • AWS クラウドの論理的に分離されたセクションをプロビジョニング(※1)し定義した仮想ネットワーク内の AWS リソースを起動することができる
  • 独自の IP アドレス範囲の選択、サブネットの作成、ルートテーブル、ネットワークゲートウェイの設定など、仮想ネットワーク環境を完全にコントロールできる
  • VPC のネットワーク設定は容易にカスタマイズすることができる。たとえば、インターネットとのアクセスが可能なウェブサーバーのパブリックサブネットを作成し、データベースやアプリケーションサーバーなどのバックエンドシステムをインターネットとのアクセスを許可していないプライベートサブネットに配置できる。
  • 既存のデータセンターと自分の VPC 間にハードウェア仮想プライベートネットワーク (VPN) 接続を作成することができるので、AWS クラウドを既存のデータセンターを拡張するかのように活用することができる。

※1 プロビジョニング:
必要に応じてネットワークやコンピューターの設備などのリソースを提供できるよう予測し、準備しておくこと

VPCをカスタマイズするコンポーネントたちと構成例

f:id:jrywm121:20180506014018p:plain

f:id:jrywm121:20180506014126p:plain

↓あとでそれぞれの項目を補足する
インターネット接続VPCのステップ

  • アドレスレンジの選択
    • 推奨: /16 65,534アドレス
  • AZに於けるサブネットの選択
    • VPCあたりのサブネット作成上限数はデフォルト200個
    • /24に設定すれば、200個作成する上で効率が良い(サブネットあたりのIPアドレス数 251)
    • サブネットで利用できないIPアドレス(/24の例)

      ホストアドレス 用途
      .0 ネットワークアドレス
      .1 VPCルータ
      .2 Amazonが提供するDNSサービス
      .3 AWSで予約
      .255 ブロードキャストアドレス
  • インターネットへの経路を設定
    • ルートテーブルはパケットがどこに向かえば良いかを示すもの
    • PublicサブネットのIPがIGW(Internet GateWay)経由でインターネットまたはAWSクラウドと通信するときにパブリックIPを利用
    • EC2のOSで確認できるのはプライベートIPのみ
  • VPCへのIN/OUTトラフィックを許可 f:id:jrywm121:20180506120927p:plain

    |ネットワークACL |セキュリティグループ| |:--:|:--:| |サブネットレベルで効果|サーバレベルで効果| |Allow/DenyをIN・OUTで指定可能(ブラックリスト型)|AllowのみをIN・OUTで指定可能(ホワイトリスト型)| |ステートレスなので、戻りのトラフィックも明示的に許可設定する|ステートフルなので、戻りのトラフィックを考慮しなくて よい| |番号の順序通りに適用|全てのルールを適用| |サブネット内のすべてのインスタンスACLの管理下に入る|インスタンス管理者がセキュリティグループを適用すればその管理下になる|

VPCとのプライベート接続

  • VPN接続 : バーチャルプライベートゲートウェイを利用したサイト間VPN
    • 1つのVPN接続は2つのIPsecトンネルで冗長化
    • ルーティングは静的(スタティック) / 動的(ダイナミック:BGP)が選択可能
  • 専用線接続 : AWS Direct Connectを利用し、一貫性のあるネットワーク接続を実現する。本番サービス向け。
    • AWSとお客様設備を専用線でネットワーク接続

VPC設計のポイント

  • CIDR(IPアドレス)は既存のVPC、社内のDCやオフィスと被らないアドレス帯をアサイ
  • 複数のアベイラビリティゾーンを利用し、可用性の高いシステムを構築
  • パブリック/プライベートサブネットへのリソースの配置を慎重に検討

VPCと他サービスとのやり取り

  • サービスによってVPC内と外のどちらにリソースやエンドポイントが存在するかが異なる
  • VPC Endpointは、グローバルIPをもつAWSのサービス(例えば、DynamoDB / Lambda / S3 / SQS 等…)に対して、VPC内部から直接アクセスするための出口です。
  • VPC EndpointはGateway型の動作とPrivateLink (Interface型)の動作に分かれる
    • Gateway
    • PrivateLink (Interface型)
      • サブネットにエンドポイント用のプライベートIPアドレスが生成される。
      • VPC内部のDNSがエンドポイント向けの名前解決に対してしてプライベートIPアドレスで回答する。
      • エンドポイント用プライベートIPアドレス向け通信が内部的にサービスに届けられる。

f:id:jrywm121:20180506101243p:plain

NATゲートウェイ

Amazon VPCの実装方法

  • マネジメントコンソール
  • AWS CLI / AWS SDK
  • Ansibleなどのサードパーティツール
  • AWS CloudFormation
    • EC2やELBといったAWSリソースの環境構築を、設定ファイル(テンプレート)を元に自動化できるサービス
    • テンプレートには起動すべきリソースの情報をJSONYAMLフォーマットのテキスト形式で記述する
    • 構築済みの環境からテンプレートを作成するツール(CloudFormer)も有益

VPC Flow Logs

  • ネットワークトラフィックをキャプチャし、CloudWatch LogsへPublishする機能
  • ネットワークインタフェースを送信元/送信先とするトラフィックが対象
  • セキュリティグループとネットワークACLのルールでaccepted/rejectされたトラフィックログを取得
  • 運用例:Elasticsearch Service + kibanaによる可視化

f:id:jrywm121:20180506104749p:plain

Amazon ECS(Elastic Container Service)

以下の資料を読んで理解を深めた。 20180220 AWS Black Belt Online Seminar - Amazon Container Services
20180313 Amazon Container Services アップデート
What is Amazon Elastic Container Service? - Amazon Elastic Container Service
Task Definition Parameters - Amazon Elastic Container Service Amazon EC2 Container Service(ECS)の概念整理 - Qiita

概要

  • Amazon EC2 Container Service (ECS) は、Docker コンテナをサポートするスケーラビリティに優れた高性能なコンテナ管理サービス
  • Amazon EC2 インスタンスのマネージド型クラスターで簡単にアプリケーションを実行できる
  • 簡単な API 呼び出しで、Docker が有効なアプリケーションを起動および停止したり、クラスターの完全な状態を問い合わせたり、セキュリティグループ、Elastic Load Balancing、Amazon Elastic Block Store (Amazon EBS) ボリューム、AWSIdentity and Access Management (IAM) ロールなどの機能にアクセスすることができる
  • Amazon EC2 Container Registry (ECR)
    • 開発者が Docker コンテナイメージを簡単に保存、管理、デプロイできる完全マネージド型の Docker コンテナレジストリ

コンテナを利用した開発に必要な技術要素

  • アプリのステートレス化
    • ステートが必要なものはコンテナの外に置く
  • レジストリ
    • コンテナの起動元となるイメージの置き場所
      • アプリ+実行環境をpush / 実行時にpull→build→run
    • 高い可用性、スケーラビリティが求められる
      • 落ちたらデプロイ不能、同時に大量にpullされることもある
      • 自前で持つとその管理コストがかかるので、Amazon ECRを利用しましょう
  • コントロールプレーン / データプレーン
    • コントロールプレーン = コンテナの管理をする場所
      • どこでコンテナを動すか / 生死の監視 / いつ停止するか / デプロイ時の配置 → Amazon ECS / Amazon EKS
    • データプレーン = 実際にコンテナが稼働する場所

f:id:jrywm121:20180506123718p:plain

Task: コンテナ(群)の実行単位

  • Task Definitionの情報から起動される
    • Task Definitionとは、jsonフォーマットのテキストファイルで、これは1つ以上(最大10)のコンテナーを記述できる
    • 記述するパラメータは以下のようなものがある
      • family : タスク定義の名前で、この名前をベースにシーケンシャルにリビジョンナンバーが付与される
      • taskRoleArn : タスク定義を登録するときに、IAM タスクロールを割り当てて、タスクのコンテナに、関連するポリシーに指定された AWS API を呼び出すためのアクセス権限を付与できる。
      • executionRoleArn : タスク定義を登録するとき、タスクのコンテナがユーザーに代わってコンテナイメージを取得して、CloudWatch にコンテナログを発行するためのタスク実行ロールを提供することができる
      • networkMode : タスクのコンテナで使用する Docker ネットワーキングモード。有効な値は、none、bridge、awsvpc、および host です。Fargate 起動タイプを使用している場合、awsvpc ネットワークモードが必要。
      • containerDefinitions
        • name : コンテナの名前。Docker Remote API の コンテナを作成する セクションの name と docker run の --name オプションにマッピングされる。
        • image : コンテナの開始に使用するイメージ。新しいタスクが開始されると、Amazon ECS コンテナエージェントは、指定されたイメージおよびタグの最新バージョンをプルしてコンテナで使用する。
        • memory : コンテナに適用されるメモリのハード制限    などなど…
  • Task内のコンテナ群は同じホスト上で実行
  • CPUとメモリの上限を指定し、それをもとにスケジュールする。

Service : ロングランニングアプリ用スケジューラ

  • Taskの数を希望数に保つ
  • Task Definitionを新しくするとBlue/Greenデプロイ
  • ELBと連携することも可能
  • メトリクスに応じてTask数のAuto Scalingも可能

IAM Role: Task毎に異なる権限のAWS認証が可能

※ タスクの単位について
例えば、裏にいるAPIをCallしてWEB UIを提供するもので、expressのアプリケーション のコンテナとnginx(expressにプロキシする) のコンテナで構成されるFront Serviceがある場合には、expressコンテナとnginxコンテナはTaskという単位でくくられる。

  • IAM RoleをTask毎に設定可能
  • AWS SDKを利用していれば自動的に認証情報が得られるため、アクセス鍵等の埋め込み不要

コンテナの数をAuto Scalingさせる

  • 何らかのメトリクス(例えば、コンテナのCPU・メモリ使用率 / リクエスト数)に応じて、コンテナの数を自動スケールさせたい
  • コントロールプレーンの課題 : メトリクスの変化に対して、コンテナ数をどの程度変化させるのか
  • データプレーンの課題 : コンテナのスケールに応じて、インスタンス数もスケールが必要

ECSのTarget TrackingとFargateの組合せがオススメ

  • Target Trackingとの連携

    • メトリクスに対してターゲットの値を設定するだけ(例: CPU使用率 50%)
    • その値に近づく様に、Application AutoScalingが自動的にServiceのDesiredCountを調整
  • Fargateを利用したコンテナAuto Scalingの優位性

    • Serviceのスケールに応じて自然にコンテナが起動・終了する
    • コンテナの起動時間に対してのみ課金