AWSを一から勉強した箇条書きメモ

仕事で AWS を利用することになり、これまで GCP ばかり利用してきたので、 AWS を一から勉強し直すことにしました。基本的には、以下の二つで紹介いただいている内容を中心に Web アプリケーションエンジニア に必要そうなものをやってみました。

• AWSの開始方法（公式）
• 【AWS初心者向け】AWS学習方法まとめ【15時間で達成できる】

この記事は、参照した Web サイト／動画／チュートリアルの内容を後で振り返るための自分用の箇条書きメモになります。

読み物

クラウド (クラウドサービス) とは？（0.5h）

https://aws.amazon.com/jp/cloud/

クラウドについての前提知識を説明してくれてます。

• クラウドサービスとは
  • IT リソースをオンデマンドで利用することができるサービスの総称
  • 従量課金が一般的
• 6つのメリット
  • 固定の償却コストが変動コストに
    • 事前にサーバを購入するのではなく、利用した際に利用した分だけ支払う
  • スケールによる大きなコストメリット
    • クラウド利用ユーザが多いので、規模の経済により料金が安い
  • キャパシティ予測が不要に
    • 必要に応じて、リソース調整／スケールアップなどを、即座に実行できる
  • 速度と迅速性の向上
    • IT リソースを簡単に手に入れられるので、開発／検証のコストと時間が減る
  • データセンターの運用保守投資が不要
    • インフラ（サーバ設置／連携／起動など）ではなく、プロダクトに集中できる
  • わずか数分で世界中にデプロイ
    • 世界中のリージョンにデプロイでき、レイテンシーを下げることができる
• 代表的なクラウドのタイプ
  • Infrastructure as a Service (IaaS)
    • クラウド上のサーバ／ストレージ／ネットワークを提供する
    • 物理的なハードウェア管理からは開放されるが、利用には専門的な知識が必要
  • Platform as a Service (PaaS)
    • 上記に加えて、開発環境／データベース／ソフトウェアライブラリなど、アプリケーションの基盤部分を提供する
    • サーバや OS のメンテナンスから解放され、アプリケーションのデプロイと管理に集中できる
  • SaaS (Software as a Service)
    • 完成した製品（サービス）を提供する
    • サービスのメンテナンスやインフラ管理から解放され、特定のソフトウェアの利用方法を覚えるだけで良い
• クラウドネイティブ技術
  • クライド
  • クラウド環境でスケーラブルなアプリケーションを構築／実行し、回復性／管理力／可観測性のある疎結合システムを実現するための技術
  • 代表例: コンテナ、サービスメッシュ、マイクロサービス、イミュータブルインフラストラクチャ、宣言型 API
• クラウドのデプロイモデル
  • クラウド
    • 完全にクラウドにデプロイされるアーキテクチャ
    • 上記の「6つのメリット」を完全に享受できる
  • ハイブリッド
    • クラウドとオンプレミスの両方のリソースに接続するアーキテクチャ
    • レガシーなオンプレ上のシステムから、クラウド上のリソースに接続することで、インフラをクラウドに拡張するようなケースが一般的
  • オンプレミス
    • オンプレミス（自社内の物理サーバ）にリソースをデプロイするアーキテクチャ
    • クラウドのメリットの多くは享受できないが、専用のリソースを提供できる

AWS の基礎（1.5h）

https://aws.amazon.com/jp/getting-started/fundamentals-core-concepts/

AWSのベストプラクティス集「AWS Well-Architected」をベースに、5つの軸で考え方を説明してくれてます。

• AWS Well-Architected
  • アプリケーションやワークロード向けに高い安全性、性能、障害耐性、効率性を備えたインフラストラクチャを構築するための、設計指針やベストプラクティス集
  • 5つの柱
    • 運用上の優秀性
    • セキュリティ
    • 信頼性
    • パフォーマンス効率
    • コスト最適化
  • 一般的な設計原則
    • キャパシティーニーズの推測が不要
    • 本稼働スケールでシステムをテストする
    • ⾃動化によってアーキテクチャでの実験が容易に
    • 発展するアーキテクチャが可能に
    • データに基づいてアーキテクチャを駆動
    • ゲームデーを利用して改善する
• セキュリティ
  • 「ゼロトラスト」モデルで考える。あらゆるコンポーネントやサービスが害を及ぼす可能性がある
  • Identity and Access Management (IAM)
    • 「誰が」「何に」「何を」できるかを管理する
      • プリンシパル: 誰に許可が付与されるかを指定する
      • アクション: 何が実行されるかを指定する
      • リソース: どのプロパティがアクセスされるかを指定する
    • 最小権限の原則
  • ネットワークセキュリティ
    • ネットワークとネットワークにアクセスできるリソースのアクセスと可用性を保護するためのメカニズム
    • 最外層だけでなく、多層防御が重要
    • VPC で、プライベートネットワークを構築
    • WAF で、外部からの攻撃からWebアプリケーションを保護
    • セキュリティグループで、 EC2／RDS／Lambda などのリソースへのアクセスを、特定のポート、信頼されたリソースからのみに制限する
  • データの暗号化
    • 転送時の暗号化
      • AWS のストレージ／データベースサービスは HTTPS エンドポイントを提供
    • 保管時の暗号化
      • AWS のストレージ／データベースサービスがサポート
      • KMS というキー管理サービスと統合されている
• パフォーマンス効率
  • クラウドでサービスを効率的かつスケーラブルに実行する方法
  • リソースをペットではなく家畜として考える（交換可能、増やせる）
  • 選択
    • サービスタイプ: VM ベース／コンテナベース／サーバレスベース
    • ストレージ: ファイルストア／ブロックストア／オブジェクトストア／アーカイブストア
    • データベース: リレーショナル／非リレーショナル／データウェアハウス／インデックス作成と検索
  • 管理レベル
    • フルコントロールからフルマネージドまで色んなラインナップがある
    • コンピューティング: EC2／Elastic Beanstalk／Lightsail
    • ストレージ: 一つしかないので簡単
    • データベース: RDS／Aurora を選択する。Aurora はMySQLとPostgreSQLのいずれかをでしか機能しないが、ストレージ管理やクラスタリングサポートをやってくれる
  • 設定
    • コンピューティング: メモリ／CPUを考慮
    • ストレージ: レイテンシー／スループット／IO特性を考慮
    • データベース: リソース要件 (CPU、メモリ、ストレージなど) を考慮
• 信頼性
  • サービスとインフラストラクチャ両方の中断に対する耐障害性を備えたサービスを構築する方法
  • 障害影響範囲を制限する
  • 3つのレベルの障害分離ゾーン
    • リソースとリクエスト
      • リクエストのたびに、リソース＋リクエストはパーティション化（＝セル）
      • セル内に障害を封じ込める。自動で行われる
    • アベイラビリティーゾーン（AZ）
      • 一つのリージョン内の物理的に離れた施設
      • 複数の AZ を使ってサービスの冗長インスタンスをデプロイできる
    • リージョン
      • 複数のリージョンにまたがって冗長インスタンスをデプロイできる
      • ただし、相当な運用オーバーヘッドは発生する
• 運用上の優秀性
  • システムを実行し、より優れた手順を作成して、洞察を得る能力を継続的に向上させる方法
  • 「オートメーション」の観点から考える
  • 現在最も「多くの手作業を必要とする分野」「エラーが最も大きい分野」に取り組む
  • Infrastructure as Code
    • 機械可読な設定ファイルを使ってインフラストラクチャを管理する
    • 設定ファイルをもとに、インフラストラクチャのプロビジョニングを自動化する
    • CloudFormation で JSON／YAML で記載する
    • 動的に設定したい場合は、CDK を使って JavaScript／JAVA／Pythonで記載することもできる
  • オブザーバビリティ
    • システム内部の状態を測定する
    • 収集
      • インフラレベル: AWSサービスにより自動生成され、CloudWatch によって収集される
      • アプリレベル: アプリケーションにより生成され、CloudWatchのカスタムメトリクスにより収集される
      • アカウントレベル: AWSアカウントにより生成され、CloudTrail により収集される
    • 分析
      • CloudWatch => CloudWatch Logs Insight
      • S３ => Athena
      • 大規模データ => RedShift
      • ログ形式 => Elasticsearch Service
    • アクション
      • モニタリングとアラーム: CloudWatch Alarms で閾値を超えたら通知
      • ダッシュボード: CloudWatch ダッシュボード
      • パフォーマンスとビジネス KPI を元にデータドリブンで意思決定をする
• コスト最適化
  • 観点をCapEx（購入モデル）からOpEx（継続的な従量制料金モデル）への移行
  • 高額な先行固定費用ではなく、少額の継続的な可変費用で考える
  • 従量制料金
    • 規模最適化: インスタンスの規模を最適化。AWS Compute Optimizer が役立つ
    • サーバーレス: Lambda を使って、使用時のみ料金を支払う
    • 予約: 長期契約で大幅割引。EC2／Fragete／Lambda／RDS／DynamoDB／CloudFront など。コンピューティングには Savings Plans を利用
    • スポットインスタンス: 普段使用されてないEC2インスタンスを利用。最大90%OFF
  • コスト最適化のライフサイクル
    • レビュー
      • AWS Cost Explorer で経時的なクラウド支出を可視化
      • 項目単位の詳細情報は AWS のコストと使用状況レポート
    • 追跡
      • コスト配分タグを使って、タグ単位にコストを分類する
      • AWS Budgets を使って、予算目標を策定し、コスト実績と予測を作成。閾値を超えたら通知もできる。
    • 最適化
      • 追跡したコスト及びリソースメトリクス、ビジネスKPIをもとに、規模最適化／サーバレス／予約／スポットインスタンスなどの導入を行う

動画（ウェビナー）

AWS ご利用開始時に最低限おさえておきたい10のこと（1h）

https://pages.awscloud.com/event_JAPAN_at-least-10-ondemand.html
上記ページで、プロフィール情報を記入して「送信」すると、資料のダウンロードページに遷移します。

• AWS Well-Architected Framework（W-A）
  • 内容は「AWSの基礎」と重複してるので割愛
  • Well-Architected_review_sheet
    • 46項目のチェックシート
    • システムの現状とベストプラクティスの差分（改善ポイント）を把握するのに使う
• セキュリティのベストプラクティス（5項目）
  • 認証情報と認証
    • AWS ルートアカウントには FMA（他要素認証）を設定して、ルートアカウントは利用しない
    • Access Key を削除する
    • IAM を利用する
  • 人為的なアクセスの制御
    • 各個人に IAM ユーザを払い出し、必要に応じて最小限の権限を付与する
    • IAMユーザ
      • 個人ごとに発行するアカウント。名前、パスワード、アクセスキーで構成
    • IAM グループ
      • IAM ユーザをまとめたもの
  • プログラムによるアクセスの制御
    • 認証情報をハードコードせずに、IAM ロールを使う
    • git-secrets という AWS の認証情報を git に commit しようとしたらエラーにするツールもある
  • セキュリティイベントの検出
    • セキュリティ関連のログを取得して、一元的に管理する
    • AWS CloudTrail で操作ログを取得／保存するサービス（現在はデフォルト ON ）
      • 保存期間を延長した方が良い（法令やガイドラインに合わせて）
    • その他のログも有効化したほうがよい（デフォルトはOFF）
      • ELB／Amazon CloudFront／Amazon API Gateway／VPC Flow Logs／Amazon S3 バケット
    • 上記のようなログを一元的に監視できるダッシュボードを作る
    • 疑わしい動きを検出した時に通知を自動化する（Amazon GuardDuty というマネージドサービスもある）
  • ネットワーク
    • 各レイヤでのセキュリティ対策。アクセス設定は最低限
    • ネットワーク ACL／EC2／RDS などの設定
    • AWS WAF（Webアプリケーションファイアフォール）／AWS Shield（DDos 攻撃）を活用
• 信頼性のベストプラクティス（2項目）
  • バックアップ
    • バックアップ取得および定期的なリカバリテスト（リカバリの方が漏れがち）
    • EC2 なら AMI、EBS ならスナップショット、RDB の自動バックアップ
  • コンポーネント（RDS／EC2など）のエラーの対処
    • 複数の論理的なデータセンター（AZ）、複数リージョンで実行
    • 疎結合なアーキテクチャ
    • 障害を検知して自動に復旧
    • 単一障害点の排除
    • RDS の MultiAZ デプロイメントは有効なのでやった方が良い
      • 同期レプリケーション＆自動フェイルオーバー
• コスト最適化のベストプラクティス（3項目）
  • 使用料とコストのモニタリング
    • 請求ダッシュボードと AWS Cost Explorer を積極的に使って把握する
    • AWS Budgets を活用し、事前に設定した閾値を超えたら通知する
  • インスタンスタイプとサイズの選択
    • メトリクスに基づいて、随時サイジングする
    • AWS CloudWatch でリソース使用率を把握できる
    • 最新のインスタンスファミリーの方が基本的に高性能／安価
  • 料金モデルの選択
    • 利用率を分析し、購入オプションを検討。リージョン毎の料金差も考慮
    • 米国リージョンの方が安い。コンプライアンスやレイテンシーに問題がなければ米国を
    • 購入オプション
      • オンデマンドインスタンス
        • 初期費用なし、従量課金
        • 利用料が増減するケースにマッチする
      • リザーブドインスタンスなど
        • 長期（1or3年）の利用コミットによる割引（最大75%）
        • 常時稼働しているサーバ（DB／キャッシュサーバなど）にマッチ
      • スポットインスタンス（EC2 のみ）
        • 余剰リソースを安価に提供
        • 分散処理のタスクロード、クローラーなどにマッチ

AWS 設計のベストプラクティスで最低限知っておくべき 10 のこと（1h）

https://pages.awscloud.com/JAPAN-event-OE-At-least-10-Architecting-2020-reg-event-LP.html

「AWSの基礎」とかぶる部分が多かったですが、大事な話が多いので追加で動画を見ました。

1. スケーラビリティを確保する
   • システムの負荷増大／用途拡大に応じて、柔軟に性能や機能向上／拡大すること
   • アプリケーションが落ちてから気づくのではなく、閾値を超えたら自動でリソース拡張されるようにする
2. 環境を自動化する
   • 自動で環境を立ち上げることで、設定ミス／作業漏れを減らし、自動復旧も可能になる
3. 使い捨て可能なリソースを利用する
   • オンプレミスのサーバのように一つ一つ名前をつけるのではなく、リソースに対して種別を表すタグをつける（＝ペットではなく、家畜として扱う）
   • 一つ一つのリソースに状態（state）を持たせないことで、使い捨て／交換可能に
4. コンポーネントを疎結合にする
   • 構成要素（コンポーネント）が互いに依存しない形にする
   • => 必要な部分だけ変更できる。障害ポイントが分かりやすくなる
   • アプローチ
     • 処理内容やデータ特性毎にコンポーネントを分ける
     • 状態（ステート）を持つレイヤと持たないレイヤを分離
     • 処理のつなぎ目を検討
       • 例）Web サーバと App サーバ間の LB、Message キュー、DNS、Event通知など
     • データ特性に合わせた最適なデータストアを選択
       • 例）Cache／File／RDB／key-valueストア
5. サーバではなくサービスで設計する
   • マネージドサービスを利用する
     • DNS => Route53
     • LB => ELB
     • Messageキュー => SQS
     • セッションデータ => ElastiCache
     • File => S3
     • RDB => RDS
     • key-valueストア => DynamoDB
     • API化 => API Gateway
     • etc.
6. 適切なデータベースソリューションを選択する
   • RDB／NoSQL／列指向／グラフDB etc.
7. 単一障害点を排除する
   • そこで障害が発生したときにシステム全体がストップするような障害点
   • 各レイヤーで冗長化、可用性を高める
8. コストを最適化する
   • AWSのコスト特性は、初期投資不要／従量課金／TCO（ランニングコスト込み）で考える
   • リソース使用状況をモニタリングして、コストを最適化していく
9. キャッシュを使用する
   • CDN、Memcached／Redisなど
   • マネージドサービスだと、ElastiCache がある
10. 全てのレイヤーでセキュリティを確保する
    • セキュリティは、ビジネスリスクの回避・継続性の担保が目的
    • 取り組む課題: リスク軽減／回復力／説明責任／運用軽減
    • セキュリティコストは、取り組むリスクの範囲とトレードオフ
    • 各コンポーネントを隔離／暗号化／アクセス権限／他要素認証／マネージドサービス／ログ／デプロイ自動化
11. 増加するデータの管理
    • クラウドでは、安価・上限なし／全データ保存／処理内容をビジネスに合わせる
    • データレイク にオリジナルデータを一元管理しておき、用途に合わせてデータを加工して処理する

チュートリアル／ハンズオン

AWS アカウントの作り方 & IAM 基本のキ（1.5h）

https://pages.awscloud.com/Hands-on-for-Beginners-1st-Step-2020_Landing-page-F35D.html

「AWS ご利用開始時に最低限おさえておきたい10のこと」でも紹介されていたように、ルートユーザとは別に IAM ユーザを作成して、そちらに適切な IAM ポリシー権限を設定して利用するようにしたほうが良さそうです。
この動画では、IAM ユーザ／ポリシー／グループ／ロールについて、実際に動作確認しながら解説くれるので、かなり分かりやすかったです。

1. アカウントを作成してみる
2. ルートユーザーと IAM ユーザーについて学ぶ
3. IAM ユーザーを作成してみる
   • AdministratorAccessポリシーをアタッチした、管理者用の IAM ユーザーを作成（他のチュートリアル／ハンズオンはこのユーザで実施する）
   • 管理者用 IAM ユーザで、AmazonS3ReadOnlyAccessポリシーをアタッチした IAM ユーザーを作成
4. IAM （ポリシー、グループ、ロール）について学ぶ
   • ポリシー: アクセス許可の定義をJSON形式で記載。ワイルドカード（*）も利用できる
   • グループ: IAM ユーザの集合を定義し、グループにポリシーをアタッチして、ユーザをグループに所属させる
   • ロール: ロールにポリシーをアタッチして、AWS リソースに割り当てることでリソースがアクションをできるようになる
5. IAM ポリシーと IAM グループを作ってみる
   • ユーザ定義の IAM ポリシーを作成する。JSON の雛形作成には、AWS Policy Generator が便利。コンソールのビジュアルエディタで指定するのもあり
   • 新しい IAM ユーザを作ってユーザ定義ポリシーをアタッチする
     • EC2 の参照だけできるストーリーなのだが、動画の内容だと色々エラーやアラームが出るので、メッセージを読んで IAM ポリシーに権限追加するのが良い練習になる
   • 新しい IAM グループを作ってユーザ定義ポリシーをアタッチする
   • 新しい IAM ユーザを作って、グループに所属させる
6. IAM ロールを試してみる
   • IAM ロールを作成し、EC2 インスタンスに IAM ロールを割り当て、インスタンスに接続して AWS CLI を使って、情報を取得する
   • 最初はポリシーを割り当ててないので情報を取得できないが、ポリシーを割り当てると取得できるようになる
7. クリーンアップ
   • EC2、S3、IAM ユーザ／グループ／ロール／ポリシーなどを削除する

基本的なウェブアプリケーションを構築する（1h）

https://aws.amazon.com/jp/getting-started/hands-on/build-web-app-s3-lambda-api-gateway-dynamodb/

Webページで「姓名」を入力すると、DynamoDB にデータが登録されるようなWebアプリケーションを構築するチュートリアルになります。
「Amplify」「Lambda」「API Gateway」「DynamoDB」を体験することができます。

• モジュール1: 静的なウェブアプリケーションを作成する
  • AWS Amplify コンソール でHello Worldを返すだけの静的HTMLを直接デプロイする
  • Amplify は、スケール可能なWebアプリを構築するためのサービスで、フロントエンドとバックエンドをデプロイできる。今回は、フロントエンドだけ利用する
  • 「dev」「stg」など、environment を分けて管理できる
• モジュール2: サーバレス関数を構築する
  • AWS Lambda コンソール でパラメータを受け取って、パラメータを含む文字列をBODYとして返す関数を作成する
  • テスト用設定を追加して、関数をテストする
• モジュール3: サーバーレス関数をウェブアプリケーションにリンクする
  • Amazon API Gateway で、API を作成する
  • リソース（エンドポイント）を作成して、Lambda 関数と統合する
  • 「dev」「stg」など、ステージ を分けて管理できる
• モジュール4: データテーブルを作成する
  • Amazon DynamoDB にテーブルを作成
  • Lambda 関数の実行ロールに、IAM ポリシーを作成・設定し、Lambda 関数が DynamoDB にアクセス可能に
    • アクセス対象のリソースは、Amazon リソースネーム（ARN）で指定する
  • Lambda 関数から AWS SDK を使用して、DynamoDB にアクセスする
• モジュール5: ウェブアプリケーションに対話性を追加する
  • HTML ページから API Gateway API を呼び出すよう変更する

継続的デリバリーパイプラインを作成する（1h）

https://aws.amazon.com/jp/getting-started/hands-on/create-continuous-delivery-pipeline/

AWS CodePipeline を利用して、

1. ソースコードを GitHub で管理
2. Webhook で変更を監視し、CodeBuild でビルド
3. ビルド後「手動承認」
4. ElasticBeanstalkで デプロイ

の4つのステージで構成される CI\CD パイプラインを構築するチュートリアルになります。
「Elastic Beanstalk」「CodeBuild」「CodePipeline」を体験することができます。

• モジュール1: Git リポジトリのセットアップ
  • チュートリアル用のリポジトリ を fork する
• モジュール2: Web アプリをデプロイする
  • AWS Elastic Beanstalk でサーバやOSを意識せず、簡単に Web アプリをデプロイする
  • 以下のワーニングが発生したので、こちら を参考に、aws-elasticbeanstalk-service-roleロールに、AutoScalingFullAccessとElasticLoadBalancingFullAccessをアタッチする
    

    2021-05-24 10:42:41 UTC+0900 WARN
    Environment health has transitioned from Ok to Warning. Initialization completed 26 seconds ago and took 2 minutes. Access denied while accessing Auto Scaling using role "arn:aws:iam::xxxxxxxxxxxx:role/aws-elasticbeanstalk-service-role". Verify the role policy.

• モジュール3: ビルドプロジェクトの作成
  • AWS CodeBuild で GitHub で管理しているソースコードをビルド（ソースコードから実行可能なパッケージを作成すること）する
• モジュール4: デリバリーパイプラインを作成する
  • AWS CodePipeline で、ビルド（CodeBuild）＋デプロイ（Elastic Beanstalk）のパイプラインを作成する
• モジュール5: パイプラインを確定およびテストする
  • パイプラインにレビューステージを追加する

Fargate を使用した Amazon ECS の開始方法（1h）

https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/getting-started-fargate.html

サーバレスでDockerコンテナを実行できる AWS Fargate を使って Docker コンテナを実行し、Amazon ECS を使ってFargateサービスをオーケストレーションするような構成で、アプリを構築するチュートリアルになります。

1. 初回実行ウィザード を開く
2. 米国東部（バージニア北部） リージョンを選択
3. コンテナとタスクの設定
   • customを選択し「設定」をクリック
   • コンテナ名にhttpd-sample、イメージにdocker.io/httpd:latest、ポートマッピングに80を設定
   • その他は特に設定しない
4. サービスの設定
   • 必要なタスクの数を2に変更
   • ロードバランサの種類をApplication Load Balancerに変更
   • 注意）これらの設定は料金がかかる可能性があるので、終わったらすぐに削除する
5. クラスターの設定
   • クラスター名だけsample-app-clusterを入力しておく
   • ネットワークやIAM設定はECSが自動でやってくれる
6. 作成
   • 5分ぐらい待つとクラスター、サービス、コンテナ、タスクが作成される
7. 動作確認
   • 直接Fargateで実行中のアプリにアクセスする
     • クラスター > サービス > タスク > ネットワーキング > パブリック IP をコピーして、ブラウザで開く
       
   • ロードバランサ経由でアプリにアクセスする
     • EC2ダッシュボード > ロードバランサ > DNS名 をコピーして、ブラウザで開く
       
   • ENI IDリンクからネットワークインターフェース定義を確認
8. Auto Scalingの動作確認
   • クラスター > サービス > 更新 > 次へ > 次へ > Auto Scaling 設定
     • Service Auto Scaling の設定を変更することで、サービスの必要数を調整するを選択
     • タスクの最小数に1、タスク最大数に3を設定（必要数はとりあえず2にしておく。状況に応じて勝手に更新される）
   • スケーリングポリシーを追加
     • スケーリングポリシータイプにターゲットの追跡
     • ECS サービスメトリクスにECSServiceAverageMemoryUtilization
     • ターゲット値に1（つまり1%）を設定
   • サービスの更新
   • クラスター > サービス名 で「必要数」「実行数」あたりをモニタリングする
     • まず必要数が増えて、数分後に実行数も増えるたらスケールアウト成功
   • ターゲット値を大きな値（例えば90%）とかにして、スケールインも確認
9. クリーンアップ
   • クラスターの削除を行うと、一通りのリソースが削除される

理解のために、チュートリアルに加え以下の点を追加で動作検証しました。

• DockerHub/httpd のイメージを利用する
• ロードバランサーも設定する
• Auto Scaling の設定をして、スケールアウト／スケールインも確認する

なんとなく使い方がイメージできたと思います。

これ以外に追加で検証したいと思うのは、

• 一つのクラスター配下に複数のサービス（Webフロントエンド／バックエンドAPI）を定義するケース
• RDSなど外部サービスと統合するケース
• dev／stg／prdなど複数環境が必要なケース

ぐらいですが、ちょっと長くなりそうなので実際に簡単なアプリを作って別記事で検証してみたいと思います。

Getting started with Amazon EKS – eksctl （1h）

ECS を知ってしまうと、もはや EKS は必要ないのでは？という気持ちにもなってきたのですが、念のため EKS のチュートリアルもやってみることにしました。

まずは eksctlを使う方のチュートリアルをやってみます。こちらは 1h ぐらいでした。
https://docs.aws.amazon.com/eks/latest/userguide/getting-started-eksctl.html

• 前提条件
  • kubectl をインストール
  • eksctl をインストール
  • 「Required IAM permissions」に関しては、「AWS アカウントの作り方 & IAM 基本のキ」で作成した管理者用 IAM ユーザを使用することにする
    • IAM コンソール > ユーザ > 認証情報 > アクセスキーの作成 でアクセスキーを作成して、CSVとしてダウンロードする
    • CSVの内容で環境変数を設定する

      export AWS_ACCESS_KEY_ID=xxxxxxx
      export AWS_SECRET_ACCESS_KEY=xxxxxxx

• Step 1: Create your Amazon EKS cluster and nodes
  • eksctl create cluster --name my-cluster --region us-west-2 --fargate を実行（20分くらいかかる）
  • コマンドラインでクラスターができてることを確認

    kubectl get svc
    > NAME         TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
    > kubernetes   ClusterIP   10.100.0.1   <none>        443/TCP   4m

• Step 2: View resources
  • EKS コンソール で作成されたクラスターの詳細を確認する
    • コマンドラインでも確認できる
      • kubectl get nodes -o wide
      • kubectl get pods --all-namespaces -o wide
  • kubanetesのコンポーネントは ここ を見て勉強する
    • ノード: 1つのVMまたは物理的なマシン。この上で 一つ以上の Pod をホストする
      • 今回二つ作成されていた
    • Pod: ストレージとネットワークリソースを共有するコンテナのグループ
      • Pod 内に複数コンテナを持つ理由は、メインコンテナをサポートする目的（参照）。 data pullers／data pushers／proxies など
      • application と database は別の Pod に配置すべき。水平 Pod スケーリングする際に、application も database も一緒にスケールされるべきではない（参照）
      • 今回は、1ノードに1 Pod が作成されていた。どちらもcoredns-6f59fbcdcfというポッドのレプリカとして作成されていた
    • コンテナ: アプリケーションのコードと、依存関係をパッケージ化したもので、どこで実行しても同じ動作が得られる
      • 今回は、eks/coredns:v1.8.0-eksbuild.1イメージが利用されていた
    • ワークロード: クラスタ上で複数ノード／Pod に実行されるひとまとまりのアプリケーション
      • 今回は、kube-systemという名前空間にcorednsというワークロードが作成され、その下に Pod が二つ実行されていた
• Step 3: Delete your cluster and nodes
  • eksctl delete cluster --name my-cluster --region us-west-2

上記のチュートリアルだと、自分で設定を全くやってないので、正直なところ使い方はいまいちわかってないですが、出来上がったコンポーネント群をコンソールで参照しつつ、kubernetes のドキュメントを見ていくと、なんとなく構成だけは分かったような気になりました。
ただし、ECS と EKS でできることの違いは結局よく分かりませんでした。どちらも初めて触った自分としては、Amazon ECS vs Amazon EKS にあるように、LB を備えオートスケーリングまで簡単に実現できる ECS のシンプルさ／柔軟さが印象に残った感じです。

さいごに

公式の説明・ウェビナー・チュートリアルと、初心者向けのコンテンツを箇条書きでメモしながらやってみましたが、なかなか良い勉強になりました。
特にチュートリアルでは、いろんなマネージドサービスを横断的に使うものだったので、実際の運用イメージが湧いて良かったです。
このほかにも大量のチュートリアルが公開されているので、時間を見つけてやってみたいと思います。