Rのつく財団入り口

ITエンジニア関連の様々な話題を書いているはずのブログです。

【感想】『AWSコンテナ設計・構築 [本格] 入門』:フルカラーのコンテナ入門本

AWSのコンテナに入門できるオレンジの本

 2021年10月発売、コンテナ界隈で話題になった本です。コンテナのことをもうちょっと知っておこうと前から読む本リストにあったのですが、Kindleで50%ポイントが貯まるキャンペーンをやっていたので購入しました。
 内容は1~3章が入門、4、5章がECS/Fargate構成での圧倒のハンズオンとなっています。自分の場合は時間がないためハンズオン実施まではとても行かなかったのですが、一式を拝読しました。

AWSコンテナ設計・構築 [本格] 入門 - Arial Blackで文字間隔を詰めると表紙タイトルに似てきますがまだちょっと違いますね。 横幅を縮めてるのかな?

Chapter 01: コンテナの概要

  • サーバー仮想化よりリソース占有率が低く、コンテナ内に依存関係を完結させ、ポータビリティが高い。
  • Dockerの基本操作。v1.13からコマンドが再編成されたので一覧表あり!
  • Dockerを複数ホストで構成されたクラスター構成でやるには、管理や負荷分散、監視や自動復旧、デプロイが必要に。これを行うのがオーケストレーター。
  • Docker SwarmなどいろいろあったがデファクトKubernetesパブリッククラウドでは独自に提供することがあり、AWSではECSがある。各種AWSサービスと親和性が高く実績がある。
  • コンテナを扱う際はThe Twelve-Factor App を参照。非機能要件の考慮も変わらず重要、アプリチームとインフラチームの協力や役割分担の見直しも大事。

12factor.net aws.amazon.com

 前にDockerの情報を見た時となんかコマンドが違うような...?と思ったら新しくなっているのですね。一覧表もあってお役立ちです。
 電子書籍で見てもフルカラーで参考URLも多く、とても見やすいです。Kindleで見ると脚注がいったん章末にジャンプするのでなく画面の下に出るのが見やすいですね。

Chapter 02: コンテナ設計に必要なAWSの基礎知識

  • コンテナを管理する機能が「コントロールプレーン」で動かすものとは別。
    • ECSは論理グループのECSクラスター>中に複数のサービス>1つ以上のコンテナからなるタスク
    • EKSはK8sの仕様通り。
  • コンテナが実際に稼働するのが「データプレーン」
    • EC2
    • AWS Fargateがフルマネージドでホスト管理不要。ただしお高いがその後値引きされてきた。総合的に見て現在はFargateがおススメ。
  • データプレーンをユーザー側のホスト上で動かせるECS Anywhereというサービスも2020/12に発表。
  • 同じく2020/12に発表されたEKS Anywhereは異なり、コントロールプレーンとデータプレーン両方をオンプレ上で。
  • コンテナを登録しておくレジストリがECR。もうパブリックなDockerイメージも使えるので、現在ではおススメ。
  • AWS Lambdaも内部的にはコンテナを使っているが違うカテゴリで、ECS/EKSと一緒には使えない。
  • 2021/5公開のApp Runnerが注目。Webアプリを素早く展開。中でコンテナイメージのデプロイもしており、ECR,ECSの動作も中で隠蔽して行っている。

  • コントロールプレーンをECSかEKSにするかの2択、データプレーンをEC2にするかFargateにするかの2択で2x2の4通り。

  • 大まかにいうとECSは実績もあり枯れていて情報も多い。EKSはバージョンアップの頻度が高くk8sの学習コストが高いが、エンジニアにとってのモチベにもなる。
  • 大まかにいうとEC2の方がデプロイが速い。Fargateは高いが管理の手間が減る。

 本書はこのECS or EKS x EC2 or Fargate の4通りについてそれぞれ、がっつりとコスト/拡張性/信頼性について解説してくれています。加えてエンジニアリング観点で枯れているか、技術者がいるか、モチベーション...などの面でも述べているのがありがたくもあり、今風です。
やっぱり組織としてしっかりコンテナをやっていこうという土台がないと、キャッチアップしていくエンジニアも大変なんだなあと思いました。

  • ユースケースごとにアーキテクチャ選択も異なる。
    • 以前からk8sを使っているならEKS。
    • ブロックチェーンは大量データの保存が必要なのでEC2を。
    • 機械学習はマシンパワーが必要でCPUよりGPUを選択がよく、FargateはGPPU未対応の制限あり。なおCPUとメモリのリソース集約率(無駄なく使うこと)は、EC2よりFargateが強い。インスタンスタイプの選択も不要。
    • SI系なら実績の多いECSで、Fargateで管理コスト減を。
    • 自社プロダクトは開発やリリース速度優先ならEKSよりECS。運用コスト減でFargateを。自社プロダクトは自分ごとと捉えられるため、エンジニアのチャレンジや対外アピールでEKSという手も。
  • ECSは元からAWSなので各AWSサービスと組み合わせてビルディングブロックを組み立てるのが容易。EKSはk8sという思想がAWSのビルディングブロックに取り込まれた形になる。たとえばロギングにCloudWatchは使えずFluentdコンテナが必要。
  • 2020/8登場のAWS Controllers for Kubernetes(ACK)は、AWSのサービスやリソースをk8sコンポーネントとして定義でき、AWSk8sをつなぐ役割として期待。

aws.amazon.com

  • AWSは今後のコンテナアップデート指針をロードマップとして提供しており、欲しい機能はIssueで手軽に申請。
  • コンテナ系サービスはよく使われるからか価格改定も継続的に行われており、Fargateも2019/1に大幅に値下げ。Saving Plansも使える。
  • AWS Summitでも2割がコンテナ系の話で注目。学習マテリアルも豊富にあり、機運が高まっていると言える。

github.com

 上のリンクにあるようにロードマップはなかなか壮観です。最後に学習マテリアルの選択フローチャートも揃っています。知らなかった情報リソースもあり、こんなにいろんなところにコンテナ周りのコンテンツが散らばってるのだなあと思いました。

Chapter 03: コンテナを利用したAWSアーキテクチャ

 ECS/Fargateを中心に、各サービスを組み合わせて実際のアーキテクチャを組み上げていくにあたっての解説の章。

  • Well-Architectedフレームワークの活用のみならず、Lens(レンズ)という特定領域の追加プラクティスもある。マネジメントとガバナンス、機械学習、分析、サーバーレス、HPC、IoT、金融サービス、SaaS、ファンデーショナルテクニカルレビュー
  • サンプルでは機能が一通り揃ったアイテム管理アプリケーションを題材に。データプレーンになるFargate上に、ECSの「タスク」としてフロントエンドApp、バックエンドAppの2つを載せる。DBはAurora。
  • 運用上の優秀性:モニタリングとオブザーバビリティ
    • CloudWatch Logsでログのフィルタリング、Slackへ通知
    • ログのルーティングの仕組みにFireLensという機能がある。fluentd, fluentbit。S3だけでなくCloudWatch Logsにも転送できる。
    • CloudWatchメトリクスで監視。CloudWatch Container Insightsという機能?を使うと、Fargateの中のECSのタスク単位でCPUやメモリなどなどがわかる。
    • トレースにはX-Rayサイドカーコンテナの中に入れ、IAM権限も必要。またコンテナからX-RayにつなげるためにVPCエンドポイントもいる。
    • コンテナはCI/CDと相性がよい。CodeシリーズやCodePipelineで。CodeCommitは全体で1つ。CodeBuild-CodeDeployはdev/stage/prodの3つごとにAWSアカウントで分離。アプリ開発が本格化するより前にCI/CDパイプラインを作るのがよい。
    • コンテナイメージはECRに登録すると、その後ろでS3に保存。置きっぱなしだとコストが掛かるのでライフサイクルを使う。
    • Bastion(踏み台)ホストを別のパブリックサブネットに作り、そこからメンテ。
  • セキュリティ設計
    • 責任共有モデルに基づき、利用者の責務のところについて対応。
    • コンテナイメージはECRで脆弱性スキャン可能。OSSでTrivyというものもある。コンテナベストプラクティスのチェックにDockle。秘密情報はSecrets Manager。
    • レジストリでの対策としてはECRの設定、IAMポリシー。
    • オーケストレーターに対してはIAM最小権限の原則。VPC内のECSタスクはネットワークモードawsvpcになる。
    • コンテナに対してはパブリック/プライベートサブネットの設定、WAFやShieldなどなど。
  • 信頼性設計
    • ECSタスクはマルチAZにまたがって配置できるので、マルチAZ構成で可用性。
    • CloudWatchで障害検知、ECSにはタスク自動復旧や切り離しの機能がある。
    • 障害時のSorryページはALBの設定でそちらに飛ばすようにする。
    • ECS系のクォータの最大数拡張は申し込むとできるが自動では行われない。Trusted Advisorで警告してくれないので注意。
  • パフォーマンス
    • W-Aの原則に従いやっていく。ビジネス上のパフォーマンス要件決定
    • ECSタスクは余裕を持って割当て
    • ECS/Fargateはスケールアップとスケールアウトの戦略が設定可能。ステップスケーリングポリシーとターゲット追跡スケーリングポリシーがある。
    • 各種ツールを使ってテスト
    • CloudWatchメトリクスで確認
    • 見直し。より頻繁に実験し、最適なリソースを見極める。
  • コスト最適化設計
    • ECSタスク数とリソースのサイジング
    • EC2でなくFargateだとCompute Saving Plansで大幅に削減できる
    • Lambdaを使ってECSタスクの稼働時間帯を調整したり
    • ECSタスクが止まるのを許容するFargate Spotを使っても安くできる
    • コンテナイメージのサイズもシェイプアップしたほうが安くなる

 全体としてはコンテナでなくEC2をVPC内に配置したときのアーキテクチャ構築の延長のような感じですが、コンテナだとさらに使うサービスや機能が増えていきます。FireLensとか初耳のワードも出てきました。
 3章も図が頻繁に出てくるのですがフルカラーでとても見やすいです。そして最初の基本のアーキテクチャに各種サービス群が加わってWell-Architectedになった構成図が最後にふたたび載っているのですが、これもフルカラーですが込み入っていてかなり複雑! コンテナが入った構成で完全にやろうとするとここまで大変になるのか...! と思いました。

 さすがにECSはAWS提供のサービスだけあって、コンテナが出てこないEC2ベースの場合と同じように定番のサービス群とうまく矢印で繋がっていますね。これがEKSだといろいろ独特なところが来るのだろうなあというのは想像が付きます。また分かると当たり前ですがEC2ベースのアーキテクチャ図で、S3-API Gatgeway-Lambdaのようなサーバーレスのアーキテクチャ図とは全く違う図になります。

 この設計を4章5章でハンズオンで実際にやっていく形になります。各設計項目で紙面の都合上全ては実施できずとのことで✗になっている箇所もあるのですが、それでも○の数が十分多い...!

Chapter 04: コンテナを構築する(基礎編)

 これまで解説してきた構成をベースに、ECS/Fargateで実際にネットワークを作りコンテナにアプリを配置していくハンズオンの章。図、スクショも豊富で圧巻のハンズオンです。

  • 今回はマネコンからの作業がベースだが実際にはCloodFormationの活用もGood。
  • ネットワークでは、昔はデフォルトVPCを残す慣習があったが今は消すのがよい。
  • EC2の時と同じように別AZにも予備のサブネットを作り、IGW、ルートテーブル、NACL/SG...
  • スタック作成はCFnを活用する。
  • サンプルアプリのフロントは、React+Next.jsベースにRails的に作れる「Blits.js」を使用。ログイン時にはORMの「Prisma」を使い、DBにもアクセス。フロントエンドだけどDBとも通信。SSRも実現している。実装はTypeScriptで、各ページの実体はReactコンポーネントなので*.tsx
  • サンプルアプリのバックエンドは、Go言語のWebアプリケーションフレームワークの代表格、echoを使いAPIサーバー。後ろでDBと接続する。
  • 通常はフロントエンドとバックエンドで別サブネットにすることが多いが、今回は同じ
  • IDEのCloud9も実体はEC2の上で動くので、ここで環境を作りGitHubからコード取得、各種用意。

  • 登録用のコンテナレジストリをECRで作っていく。

    • 実体はS3に登録なのでVPCエンドポイントも作成。けっこう作業が多い。
    • Cloud9が動いているEC2はEBSのディスク容量が少ないので拡張がいる。
    • Cloud9用のIAMロールを作成。
    • Cloud9上でコンソールから> docker imageでコンテナ作成。タグ付けしてから、> aws ecr コマンドで認証を通過、その後> docker image push でECRに登録される。マネコンで確認できる。
    • ECRからの取得もコマンドで > docker image pull で、> docker container run...で実行。
  • ECS/Fargateでオーケストレーターを構築していく。

    • ちなみにFargateではFirecrackerというマイクロVMの上でコンテナが動く。ここがLambdaと同じ模様。
    • 実行時のログをCloudWatch Logsに出すのでVPCエンドポイントを作成。
    • 外部アクセスはELBで受け取るので作成、Blue/Greenデプロイ用にターゲットグループを複数作る。
    • ECSは2020/12にUIが新しくなったが、Blue/Greenデプロイをするので今回は古いコンソール。
    • ECS作成、タスク、ECSクラスター作成、ECSサービス作成...とマネコンでやっていく。けっこう手順が長い。
    • 最後はcurlコマンドでAPI側のURLを叩き、結果とCloudWatch Logsで疎通確認。
    • その後ECS上でタスクを起動、ALBと紐づけるとフロントエンドAppが起動。めでたくブラウザ画面が見られる。
  • なお2021/3のAmazon ECS Exec発表で、Session Managerを使ってFargateコンテナへもアクセスできるようになり、デバッグが可能になった。

  • DB構築

    • セキュリティグループを作り、Auroraインスタンスを作成。手順多め。
    • Cloud9のインスタンス上のコマンドで、MySQLでユーザーやテーブルを作ったり。ここはオンプレと変わらない。
    • データ投入はINSERT文でなく、フレームワークのBlits.js+Prismaが備えているmigrateコマンドを活用。「筆者の趣味で」と書いてあります!笑
    • DB接続の認証情報はお作法のSecets Managerへ。VPCエンドポイントも必要。ECSタスク定義の更新でコンテナに読み込ませる。
    • 確認はやはりcurlコマンドでAPIを叩き、DBの中身がとってこれるかで。
  • 完成版の疎通確認

    • 完成版のアプリをdockerコマンドでECRに登録。コンテナ定義のタグを修正して更新。
    • DB接続の環境変数を読み込ませ、ECSタスクはいったん解除して新しく登録
    • めでたくブラウザからフロントエンドアプリへログインできる。おうまさんとたぬきさん(?)がいる初期画面がかわいい。

 スクショにも丁寧に矢印や解説がついておりとても綺麗です。コンテナだとここまで作業してやっと動くのか...!と圧巻されました。
 余談ですがAWS関係の本でBlitz.jsの名を初めて見ました(笑)。フロントエンド界隈の技術でTypeScript統一でフロントもバックもひとまとめのフルスタックフレームワーク、React版のRuby on Rails的になるべく少ない手間でアプリを作れるようにしてしまおう..という思想のものですね。v0.45.4ですしこれからもっと流行るかというと謎ですが、なかなか珍しい取り合わせです。作者さんの推しなのではと邪推しつつ5章に進みます。

blitzjs.com

www.prisma.io

Chapter 05: コンテナを構築する(実践編)

 4章のアプリにさらに3章の設計ポイントを当てはめていくハンズオン。こちらも図が豊富、スクショも豊富の圧巻の章が続きます。

  • Codeシリーズを使ったCI/CD環境

    • CodeCommitのリポジトリを作成、Cloud9がGitHubを向いていたので変更。
    • CodeBuildはビルドしよう定義ファイルのbuildspec.yamlの中で、事前に> aws ecrコマンドでECRにログイン、コマンドで> docker image build で作り、> docker image push でECRに登録するよう書く、という塩梅。
    • CodeBuildはマネコンでも作業が必要。けっこう長い。
    • CodeBuildで起こる「Too Many Requests.」問題について本書では詳しく解説。
    • CodeDeployはECS作成時点で自動生成される。
    • CodePipelineはアプリケーション仕様ファイルのappspec.yamlは短く、他にタスク定義ファイルのtaskdef.jsonも作成。こちらの方が長い。マネコンでも隠し設定。
  • イメージへの追加設定

    • ECRリポジトリのライフサイクルポリシーで古いものは消すように。プッシュ時の脆弱性スキャンもマネコンから。
  • 水平スケールでHA向上

    • タスクより上の単位のECSサービスに対し、Auto Scaling設定をマネコンから追加。
    • Cloud9のインスタンスAmazon Linux2で、標準で入っているApacheの負荷ツール、abコマンドで効果を確認。
  • アプリケーションへの不正アクセス防止

  • ログ収集基盤の構築

    • ログ保存用にS3バケット作成、ログを渡すFireLens用コンテナのイメージを作成
    • CloudWatchでログが混ざらないようにロググループ作成
    • ECSでタスクを作り各種設定
  • FargateによるBastion(踏み台ホスト)構築

    • Bastion用のコンテナを作り、ECRにpush
    • ECSが使うIAMロールとポリシー設定、System Manager用のIAMロール作成
    • System Managerへ繋ぐためのVPCエンドポイント作成
    • Systems Managerのインスタンスティアをアドバンスドに変える
    • Bastion用コンテナの分をECSでタスク作成
    • タスク起動でコンテナが動いたら、Systems Managerのセッションマネージャーから繋ぐとLinuxシェルでログインできる。Auroraクラスターへもmysqlコマンドでつながる。
  • セキュリティ設計:Trivy/Dockleによるセキュリティチェック

    • CodeBuildでビルド時に使われるbuildspec.ymlに、TrivyとDockleを組み込む。最新バージョンを推奨。
    • するとCodeBuildの実行エラーログに出力。
    • またビルド終了後にS3にアーティファクトが格納される。マネコンから選んでいってJSONファイルをダウンロード。TrivyとDockle両方が出る。

 4章にも登場しますがECRは3文字名前のサービスとして登場しますが、実作業としてはdockerコマンドの宛先に出てくるくらいでコンテナの置き場所的なイメージなのですね。
 Bastion(踏み台ホスト)はAWS関連でよく出てきますが、これをFargateで立てるという珍しい(?)例が本書では詳しく取り上げあられています。

まとめ:AWSのコンテナ(特にECS)の理解が深まる本

 フルカラーで文章も図もとても見やすく、コンテナ全般についても入門できます。コンテナ自体の解説は割とあっさりめ、途中からはECS/Fargateの構成で深く踏み込んでいきます。
 クラスメソッドさんの書評にある通り、日本で唯一のECSについて詳しく書かれた本なのではないでしょうか。4章5章のハンズオンも圧倒的です。あとがきを見ると多数の方がレビューにも参加されており、ここまでの本とハンズオンを作り上げるにはかなり手間がかかったことだろうなあと苦労が忍ばれます。

 自分の場合はコンテナ関係はAWS認定で出題される範囲まで、名称+αの雰囲気でしか分かっていなかったので、読んだだけですが前より理解の解像度が上がりました。(まあAWS自体、雰囲気でしか分かっていないのですが!w)

 そして本書でなくAWSのコンテナ周りについては、素人目には構成図上も結構やること多くて大変だな~という所感も持ちました。もう実際に動いているシステムで触っていったり、会社や組織単位でコンテナをやっていくぞ!という流れや体制がないと追い続けるのも大変そうですね。本書はECSにフォーカスしていますがEKSを使う場合も本書の4,5章と同じぐらいのボリュームでまた違うやり方が必要でしょうから、また別の1冊の本ぐらいになってしまうのでしょう。
また個人的にはコンテナ構成とサーバーレスの使い分けもどこかで深堀っていきたいなと思いました。

 いずれにせよAWSのコンテナについて専門的に扱ったほぼ唯一の商業書籍。より学びたい方にはお勧めの1冊です。

APN AWS Top Engineersに輝く作者の新井雅也さん(id:iselegant) のブログ記事。 iselegant.hatenablog.com

監修に当たったおなじみササキさん(id:dkfj)の記事。 blog.takuros.net

NRIの会社サイトのブログにも記事があります。 atlax.nri.co.jp

こちらもおなじみクラスメソッドさんの書評記事。 dev.classmethod.jp

AWSコンテナ設計・構築 [本格] 入門