まとめた本のタイトル
AWSコンテナ設計・構築［本格］入門
目的
AWSのコンテナサービスを理解し、開発環境を取り巻く技術動向に対し順応できるようにするため。
※この本は5章まであるが、4章と5章はハンズオンであるため、文字としてまとめるのは1から3章に留める。
1章
この章ではコンテナとそれを扱うソフトの理解を目的としている。
【コンテナとは】
他のプロセスとは隔離された状態でOS上にソフトウェアを実行する技術
【コンテナ利用のメリット】
・環境依存からの解放
コンテナにはアプリの稼働に必要となるランタイムやライブラリを1つのパッケージとして全て含めることができる。そうすることでアプリの依存関係をすべてコンテナ内で完結できる。
依存関係を含めたパッケージがリリース単位となる
・環境構築やテストに要する時間の削減
優れた再現性とポータビリティ。
全ての依存関係がコンテナ内で完結するため、オンプレでもクラウドでも起動する。
ステージング環境でテスト済みのコンテナイメージをプロダクション環境向けに再利用することで、ライブラリ差異による環境ごとのテストに必要な工数を削減できる。
・リソース効率のアップ
サーバー仮想化では、仮想マシンレベルでリソースを分離し、ゲストOS上でアプリが起動する。つまり、アプリだけでなく、ゲストOSを動かすためのコンピューティングリソースが必要。
一方コンテナは、プロセスレベルで分離されてアプリが稼働する。OSから見ると単に１つのプロセスが稼働している扱いになる。
【Dockerとは】
コンテナのライフサイクルを管理するプラットフォーム
アプリをコンテナイメージとしてビルドしたり、イメージの取得や保存、コンテナの起動をシンプルに行える。
アプリのソースコード + Dockerfile
↓ buildでイメージの作成
イメージ(アプリケーションと依存関係がパッケージングされる。アプリ、ライブラリ、OS)
↓ ship でイメージの保存
レジストリに保存
↓ run コンテナの実行
オンプレやクラウドなどで起動
【Dockerfileとは】
イメージを構築するためのテキストファイル。
このファイルにコマンドを記述することで、アプリに必要なライブラリをインストールしたり、コンテナ上に環境変数を指定したりする。
1章まとめ、感想
コンテナの登場により、本番・開発環境ごとにサーバーを立ててコマンドや設定ファイルを正確に行い、環境差異によるエラーをつぶしていき...というこれまでの数々の労力を減らすことができるようになった。
2章
この章ではコンテナサービスをコントロールプレーン、データプレーンという概念を切り口として、コスト、拡張性、信頼性、エンジニアリングを論じていく。ここではECS Fargateに話を絞って書き、他は割愛する。
AWSが提供するコンテナサービス
コントロールプレーン
・コンテナを管理する機能
コントロールプレーンは2種類
ECSとEKSがある。
ECS
フルマネージドなコンテナオーケストレータ。
オーケストレーションサービスであり、コンテナの実行環境ではない。
ECSの月間稼働率は99.99%であることがSLA として保証。
タスク
コンテナが動作するコンポーネント。
タスクは1つ以上のコンテナからなる
アプリを起動するためにはコンテナが必要。
タスク定義
タスクを作成するテンプレート定義。JSONで記述。
デプロイするコンテナイメージ、タスクとコンテナに割り当てるリソースやIAMロール、Cloud Watch Logsの出力先などを指定する。
サービス
指定した数だけタスクを維持するスケジューラーで、オーケストレータのコア機能にあたる要素。サービス作成時は起動するタスクの数や関連づけるロードバランサーやタスクを実行するネットワークを指定。
クラスター
サービスとタスクを実行する論理グループ
データプレーン
コンテナが実際に稼働するリソース環境
2種類ありECSとFargateがある。 Fargateに絞って書く
Fargateとは
サーバーレスコンピューティングエンジン
AWSのフルマネージドなデータプレーンとして定義されている
コンテナ向けであるためEC2のように単体では使用できず、ECSかEKSで利用する
Fargate メリット
ホスト管理が不要であること
サーバーのスケーリング、パッチ適用、保護、管理にまつわる運用上のオーバーヘッドが発生しない。これにより、アプリ開発に専念できるようになる
Fargate デメリット
・価格がEC2より高い。
・利用者がコンテナの稼働するOSには介入できない
・コンテナごとにENIがアタッチされるため、コンテナごとにIPが振られるため起動に若干時間がかかる
ECR
フルマネージドなコンテナレジストリ
コンテナイメージを保存、管理できる
コンテナが利用されているサービス
・Lambda
・App Runner
Lambda
利用者がコードをアップロードするだけでコードを実行できるサービス。AWS側で基盤となるコンピューティングリソースを構築してくれるフルマネージドサービス。
App Runner
2021年5月にGA(一般公開)となったサービス。プロダクションレベルでスケール可能なwebアプリを素早く展開するためのマネージドサービス。Githubと連携してソースコードをApp Runnerでビルドとデプロイができるだけでなく、ECRのビルド済みコンテナイメージも即座にデプロイできる。
ECSとFargateの場合、ネットワークやロードバランシング、CI/CDの設定などインフラレイヤに関わる必要があり、ある程度のインフラ知識は必要になる。App Runnerはそれらインフラ周りをすべてひっくるめてブラックボックス化し、マネージドにしていることが特徴である。
ECS Fargateを利用した場合のコスト、拡張性、信頼性、エンジニアリング観点
【コスト】
EC2より料金は割高。ただし、年々料金は下がってきている。
【拡張性】
デプロイの速度 遅め
理由1 コンテナごとにENIが割り当てられるため。ENIの生成に時間がかかる
理由2. イメージキャッシュができないため。コンテナ起動時にコンテナイメージを取得する必要がある。
タスクに割り当てられるエフェメラルストレージは200GB。容量は拡張不可。ただし永続ストレージの容量が必要な場合はEFSボリュームを使う手もある。
割り当て可能リソースは4vCPUと30GB。機械学習に用いるノードのような大容量メモリを要求するホストとしては不向き
【信頼性】
Fargateへのsshログインは不可。Fargate上で起動するコンテナにsshdを立ててsshログインする方法もあるが、セキュアなコンテナ環境にsshの口を開けるのはリスキーである。他にSSMのセッションマネージャーを用いてログインする方法もあるが、データプレーンがEC2の時に比べると手間がかかる。
しかし、2021年3月にAmazon ECS Execが発表され、コンテナに対して対話型のシェルや1つのコマンドが実行可能となった。
【エンジニアリング観点】
Fargateの登場からしばらく経過し、有識者や経験者は増え、確保しやすい。
・システム要件の確認
多数のユーザーに使ってもらう
可用性を高めるためにマルチAZ構成を取る
CI/CDパイプラインを形成し、アプリリリースに対するアジリティを高める
各レイヤで適切なセキュリティ対策（不正アクセス対策、認証データの適切な管理、ログ保存、踏み台経由の内部アクセス）を施したい
2章まとめ、感想
AWSが提供するコンテナサービスにはいくつかあり、なかでもFargateというフルマネージドなデータプレーンがよく使われている。ホスト管理が不要でインフラ関連の工数を削減できる一方、EC2より料金が高く、起動に若干時間がかかるのが難点である。
3章
この章では運用設計、ロギング設計、セキュリティ設計、信頼性設計、パフォーマンス設計、コスト最適化設計という様々な設計観点から、どのサービスやオプションと連携することで高い目標を達成できるかについて述べている。
【運用設計】
Fargate利用時のシステム状態を把握するためのモニタリングやオブザーバビリティに関する設計、不具合修正やデプロイリスク軽減のためのCI/CD設計が必要である。
モニタリングとは
システム内で定めた状態を確認し続けることであり、その目的はシステムの可用性を維持するために問題発生に気づくこと
オブザーバビリティとは
システム全体を俯瞰しつつ、内部状態まで深掘できる状態
オブザーバビリティの獲得によって、原因特定や対策の検討が迅速に行えるようになる
【ロギング設計】
・cloud watch logs
他のAWSサービスとの連携も容易
サブスクリプションフィルターで特定文字列の抽出も容易
・Firelens
AWS以外のサービスやAWS外のSaaSと連携することも可能
Firehoseを経由してS3やRed shift やOpenSearch Serviceにログを転送できる
Fluentdやfluent bitを選択できる
fluent bitを利用する場合、AWSが公式に提供しているコンテナイメージを使用できる
【セキュリティ設計】
・イメージに対するセキュリティ対策
- ソフトウェアやライブラリの脆弱性は日々更新されており、作ってから時間が経ったイメージは脆弱性を含んでいる危険がある。
- 方法
脆弱性の有無はECRによる脆弱性スキャン、OSSのtrivyによる脆弱性スキャン
継続的かつ自動的にコンテナイメージをスキャンする必要があるため、CI/CDに組み込む必要がある。しかし頻繁にリリースが行われないアプリの場合、CICDパイプラインが実行されず、同時にスキャンもなされないということになるため、定期的に行うスキャンも必要になる。
cloud watch Eventsから定期的にLambdaを実行してECRスキャンを行わせる（スキャン自体は1日1回のみ可能）
・提供元が不明なベースイメージの使用は避ける
・IAMポリシーによるECRのパブリック化の禁止
- オペレーションミスによる公開を防ぐことができる
【信頼性設計】
・マルチAZ構成
Fargateの場合、サービス内部のスケジューラが自動でマルチAZ構成を取るため、こちらで何かする必要はない。
・障害時切り離しと復旧
ECSはcloud watchと組み合わせることでタスク障害やアプリのエラーを検知できるうえに、用意されてるメトリクスをcloud watchアラームと結びつけて通知を自動化できる
ALBと結びつけることで、障害が発生したタスクを自動で切り離す
・リタイアという状態
AWS内部のハードウェア障害や、セキュリティ脆弱性があるプラットフォームだと判断された場合、ECSは新しいタスクに置き換えようとするその状態のこと。
Fargateの場合、アプリはSIGTERM発行に対して適切に対処できる設定にしておかなくてはならない。そうしておかないとSIGKILLで強制終了されてしまう。データ不整合などが生じて危険。
・システムメンテナンス時におけるサービス停止
ALBのリスナールールを変更し、コンテンツよりもSorryページの優先度を上げることで対処可能
・サービスクォータという制限
意図しない課金増加から保護するために設けられた制限
自動でクォータは引き上がらない
cloud watch メトリクスなどで監視する必要がある。
【パフォーマンス設計】
パフォーマンス設計で求められることは、ビジネスで求められるシステムの需要を満たしつつも、技術領域の進歩や環境の変化に対応可能なアーキテクチャを目指すこと
ビジネス上の性能要件を把握することが前提
利用者数やワークロードの特性を見極めつつ、性能目標から必要なリソース量を仮決めする
FargateはAutoscalingの利用が可能で、ステップスケーリングポリシーとターゲット追跡スケーリングポリシーがある。どちらのポリシー戦略をとるかを事前に決める
既存のワークロードを模倣したベンチマークや負荷テストを実施してパフォーマンス要件を満たすかどうかを確認する
・スケールアウト
サーバーの台数を増やすことでシステム全体のコンピューティングリソースを増やそうとする概念。可用性と耐障害性が上がる。既存のタスクを停止する必要は原則ない。
スケールアウト時の注意
・Fargate上のECSタスク数の上限はデフォルトでリージョンあたり1000までであること。
・VPCのIPアドレスの割当量に気をつける
ECSタスクごとにENIが割り当てられ、タスク数が増えるごとにサブネット内の割当可能なIPアドレスが消費されていく。スケールアウトによるIPアドレスの枯渇に注意。
Application Autoscaling
Fargateで使用可能
Cloud Watchアラームで定めたメトリクスの閾値に従ってスケールアウトやスケールインを行う
ステップスケーリングポリシー
ステップを設けて制御する
CPU使用率が60~80%ならECSタスク数を10%増加し、80%以上なら30%増加する、という任意のステップに従ってタスク数を増減させる
ターゲット追跡スケーリングポリシーとは
指定したメトリクスのターゲット値を維持するようなにスケールアウトやスケールインを制御する方針
ターゲット追跡スケーリングポリシー
メトリクスがターゲットの値を超えている場合のみスケールアウトする仕様となっている。下回っている場合のスケールアウトは定義不可
ターゲット追跡スケーリングポリシーは、スケールアウトは高速、スケールインは緩やかに実行される。
それは急激なスケールインによるサービス可用性への影響を抑えるためである。
ターゲット追跡スケーリングポリシーの良い点
利用者側でチューニングすべき事項が最小限であること。
コストとパフォーマンスのバランスがとれるところに収束すること
【コスト最適化設計】
・ECRのコンテナイメージのメンテナンス
コンテナのイメージサイズに応じて課金されるため、不要なイメージは削除することが望ましい
・開発環境やステージング環境の稼働時間帯の調整
24時間稼働している必要がなければcloud Watch eventから定期的にLambdaを起動し、ECSタスク数を調整することで、夜間の稼働をなくし、コスト削減に繋げられる
全体を通しての感想
本に載っている環境と実際の現場での環境はやはり大きく異なっている。基本的なこと、やるべきことはもちろんそれほど変わらないが、現実のシステムはさまざまな制約・条件から大変複雑であり、その都度要求にあうものを考えていかなくてはならない。
今回学んだことはあくまで基礎として吸収し、実際の現場で役立てられる場面ではそれを生かしていきたい。