【AWS】SAA資格取得のための学習用備忘録(コンピューティングサービス)

AWSにおけるコンピューティングサービス

コンピューティングは、アプリケーションを稼働させるインフラサービスで、システムアーキテクチャの中核を担う。

EC2：仮想サーバーを提供するコンピューティングサービス。必要な数だけすぐにサーバーを立てることができる、いわゆるIaas型のサービス。ELBやAuto Scalingといったサービスと組み合わせることで、負荷に応じて動的にサーバーの台数を変更するクラウドらしい使い方もできる。

ECS：Dockerコンテナの実行環境を提供するサービス。このサービスが登場するまでは、AWSでDockerを利用するためには、EC2上にコンテナ管理用のソフトウェアを導入する必要があった。ECSはサービスとしてDocker環境を提供してくれるため、利用者が設定・構築する項目を減らすことができる。

Lambda：サーバーを用意しなくてもプログラムを実行できる環境を提供するサービス。サーバーを用いないアーキテクチャ、すなわちサーバーレスアーキテクチャの中心と言えるサービスで、拡張性やコスト効率の面でメリットがある。サーバーのセットアップやメンテナンスの必要がないためアプリケーションの開発に集中できる。

これらのサービスはどれが優れている、劣っているというものではなく、機能要件や非機能要件に応じて適切なものを選択する、もしくは組み合わせて利用するもの。

★EC2は仮想サーバーを提供する

★ECSはDockerコンテナの実行環境を提供する

★Lambdaはサーバーなしでプログラムを実行する環境を提供する

EC2

オンプレミスな環境でサーバーを用意する場合、OSのインストールはもちろん、サーバーの調達、ラックの増設、ネットワークの電源や管理といった様々な作業が必要になる。

サーバーの増設にはリードタイムがかかるため、新しいサービスを構築するときには時間をかけて見積もりを行い、必要に応じて余裕率をかけたスペックの環境を用意していた。

しかし、このような見積は往々にして外れる。

予想を超えるリクエストを処理できずにビジネスチャンスを逃したり、逆にサービスの人気が出ずにインフラリソースを余らせるといった事態になり、結果として赤字が続いてしまうことがあった。

EC2は仮想サーバーを提供するコンピューティングサービス。

インスタンスという単位でサーバーが管理され、何度かボタンクリックするだけで、あるいはCLIからコマンドを1つ叩くだけで、新しいインスタンスを作ることができる。

そのため、オンプレミス環境に比べてサーバー調達のリードタイムを非常に短く設定できる。

サービスリリース前に最低限の見積は必要だが、リリース後に想定以上のペースで人気が出たとしても、インスタンスの数を増やす、あるいはインスタンスの性能を上げる調整をすれば対応できる。

また、残念ながらすぐに人気がでなかったときも、インスタンスの数を少なくしたり、スペックの低いインスタンスに変更することで、無駄なインフラ費用を払い続けなくて済む。

このように、EC2を用いることでインフラリソースを柔軟に最適化することができる。

そのため、事前の見積もりに時間をかけるのではなく、リリースまでの時間をいかに短縮するか、リリースした後のトライアンドエラーや改善活動をいかにすばやく回すかといった、ビジネス的に価値を生む行為に注力することができる。

また、カスタマー向けサイトだけではなく、社内の基幹システムでもAWSを利用することが増えてきている。

繁忙期と閑散期でインフラリソースの数を動的に切り替える、新しい施策を検証するための環境を3ヶ月だけ用意する、というように柔軟にインフラリソースを利用できるため、内部向けシステムでもEC2のメリットは非常に大きい。

EC2を起動するときは、元となるイメージを選んでインスタンスを作成する。

このイメージのことをAMIと呼ぶ。

AMIにはAWSが標準で提供しているものや、各ベンダーがサービスをプリインストールしたAMIがある。

また、各利用者がインスタンスの断面をAMIとしてバックアップすることも可能。

AMIを有効活用することで、構築の時間を短縮したり、同じインスタンスを簡単に増やしたりすることができる。

★EC2を使うとサーバーインスタンスの個数や性能を柔軟に変更できるため、コスト削減や時間短縮が実現できる

EC2における性能の考え方

EC2ではインスタンスタイプという形で、インスタンスのスペックを選択することができる。

インスタンスタイプは「m5.large」や「p3.8xlarge」といった形で表記される。

先頭の「m」や「p」はインスタンスファミリーを表し、何に最適化しているインスタンスタイプかを意味する。

例えば、コンピューティングに最適化したインスタンスタイプは「c」から始まる「c5」や「c4」タイプ、メモリに比重を置くインスタンスタイプは「r」から始まる「r5」や「r4」といった具合になる。

インスタンスファミリーの後ろの数字は世代を表し、大きいものが最新となる。

一般的に世代が新しいものの方がスペックが良かったり、安価だったりする。

「large」や「8xlarge」の部分がインスタンスサイズを表し、大きいものほどスペックが高いインスタンスタイプになる。

また、インスタンスの性能を決める他の重要な要因として、ディスク機能であるEBSがある。

EC2では通常の通信で使用するネットワーク帯域と、EBSとのやり取りで利用する帯域を共有している。

そのため、ディスクI/O、外部とのリクエストともに多く発生する場合、帯域が足りなくなってしまうことがある。

このような時に利用できるオプションが、EBS最適化インスタンス。

このオプションを有効にすると、通常のネットワーク帯域とは別に、EBS用の帯域が確保される。

そのため、ディスクI/Oが増えても、外部との通信に影響が出なくなる。

EBS最適化インスタンスはある程度大きめのインスタンスタイプでしか利用できないため、公式ドキュメントでオプションを利用できるかどうか確認する。

EC2における費用の考え方

EC2は、インスタンスを使った分だけ課金される重量課金型のサービス。

EC2のコストは、

・インスタンスがRunning状態だった時間

・Running状態だったインスタンスのインスタンスタイプ、AMI、起動リージョン

によって決まる。

インスタンスには、起動中、停止中、削除済みの3つの状態がある。

EC2では起動しているインスタンスのみが課金対象となるため、一時的に停止中ステータスにしたインスタンスや削除したインスタンスは課金対象にならない。

ただし、停止中のインスタンスでもEBSの費用はかかる点に注意。

起動しているインスタンスは、インスタンスタイプによって課金される。

この費用はリージョンやインスタンスのAMIによっても異なる。

スポットインスタンスとリザーブドインスタンス

EC2はオンデマンドインスタンス以外に、スポットインスタンスとリザーブドインスタンスという利用オプションがある。

スポットインスタンスは、AWSが余らせているEC2リソースを入札形式で安く利用する方法。

開発用の環境や機械学習のデータ学習のために一時的にスペックの大きいインスタンスを利用したいといった用途であれば、相性が良いオプションといえる。

リザーブドインスタンスは、長期期間の利用を約束することで割引を受けられるオプション。

サービスをリリースしてからしばらく経ち、インスタンスタイプを固定できると判断できた時点でRIの購入を検討すると良い。

★入札形式で安く利用できるスポットインスタンスは、インスタンスを一時的に利用したい場合などに検討すると良い

★長期間の利用で割引を受けられるリザーブドインスタンスは、システムが安定したときなどに検討すると良い

インスタンスの分類と用途

ソリューションアーキテクトが行う設計業務の中には、アプリケーションの用途に応じて適切なインスタンスタイプを選ぶというものがある。

そのためには、分類方法と、インスタンスファミリーごとの主要な用途を把握しておく必要がある。

現状は5つに分類されている。

・汎用：一番利用の範囲が広くCPUとメモリのバランス型。M5やT3などが該当

・コンピューティング最適化：CPUの性能が高い。現状はC5などのC系統のみ

・メモリ最適化：メモリ容量が大きいもの。R5やX1など複数の系列があるが、一般的な利用でのメインはR系

・高速コンピューティング：GPUなどCPU以外の計算リソースが強化されている。かなり細分化されているが、画像処理用のP系と機械学習ようのG系をまずは押さえる。

・ストレージ最適化：かなり細分化されているが、HDDを利用するD2とSSDを利用するI3を覚えておく

Sarvings Plansとスケジュールされたリザーブドインスタンス

リザーブとインスタンスと比較して、より柔軟な形で割引を享受できるプランとして、2019年11月からSarvings Plansというサービスが提供されている。

リザーブドインスタンスとの違いは、インスタンスの利用数ではなく、EC2インスタンスの利用額に対してコミットする点。

Sarvings Plansには、Compute Sarvings PlansとEC2 Instance Sarvings Plansの2種類があり、EC2 Instance Sarvings Plansは従来のリザーブドインスタンスと同じようにリージョンやインスタンスファミリーを指定して購入する。

Compute Sarvings Plansは、リージョンやインスタンスファミリーと関係なく、すべてのEC2インスタンスを対象に時間単位あたりの利用料を指定して購入する。

また、EC2のみならずLambda、Fargateも対象となっている。

かなり柔軟性が高く、うまく使えばより有利な条件でコンピューティングリソースを利用できる。

また、リザーブドインスタンスの買い方のパターンとして、スケジュールされたリザーブドインスタンスというものがある。

これは、１年間のうちに毎日、毎週、毎月の一定時間のみ使うというパターンで、平日日中のみ使うという場合などに利用料を削減できる可能性がある。

対象インスタンスが、C3、C4、M4、およびR3と少なく、最新のインスタンスに対応していないが、そういった削減方法があるということは把握しておく。

ELB

 これまで単一のEC2インスタンスについて考えてきた。

リリースしたサービスの人気が出て負荷が上がってきたとしても、AWSでは多くのインスタンスタイプが用意されているため、ある程度まではインスタンス対応を上げることで対応できる可能性がある。

このような垂直にスペックを上げる対応をスケールアップと呼ぶ。

しかし、スケールアップには限度があり、いずれインスタンスタイプの上限にぶつかってしまう。

また、単一インスタンスで運用を続けると、「そのインスタンス停止＝サービス全体の停止」という状況になってしまう。

このような「ある特定の部分が止まると全体が止まってしまう」箇所のことを単一障害店(SPOF)と呼び、単一障害点のある設計は推奨されない。

いかに単一障害点を作らないか、という視点は大切になる。

高負荷に耐えられる設計にするにはそうすれば良いか。

Webサーバーのレイヤーでベストプラクティスとなっているのが、EC2インスタンスを複数並べ、その前段にロードバランサーを配置してリクエストを各インスタンスに分散させる。

ロードバランサーとしてはEC2上にBIG-IPといった製品を導入することもできるが、ロードバランサーのマネージドサービスであるELBを利用することを推奨。

★いかに単一障害点を作らないか、という視点は試験で重視されている

★高負荷に耐えるためにEC2インスタンスのスペックを上げる対応をスケールアップと呼ぶ

★スケールアップには限界があり、単一EC2インスタンスでの運用はそのインスタンスが単一障害点になる可能性がある

★EC2インスタンスを複数用意して、それらに負荷分散することで高負荷に耐える対応をスケールアウトと呼ぶ

★ロードバランサーのマネージドサービスであるELBは、スケールアウト時の負荷分散を担う

ELBの種類

ELBには3タイプのロードバランサーがある。

・CLB：L4/L7での負荷分散を行う

・ALB：L7レイヤーでの負荷分散を行う。CLBよりも後に登場し、機能も豊富に提供されている

・NLB：L4レイヤーでの負荷分散を行う。HTTP(S)以外のプロトコル通信の負荷分散をしたいときに利用する

CLBとALBは同じアプリケーションレイヤーでの負荷分散を行うが、後継サービスであるALBの方が安価で機能も豊富。

具体的な機能としては、WebSocketやHTTP/2に対応していること、URLパターンによって振り分け先を変えるパスベースルーティング機能が提供されていることなどが挙げられる。

NLBは、HTTP(S)以外のTCPプロトコルの負荷分散を行うために用いられる。

ロードバランサー自体が固定のIPアドレスを持つなどの特徴がある。

ELBの特徴

マネージドサービスであるELBを用いるメリットとして、ELB自体のスケーリングが挙げられる。

EC2インスタンス上にロードバランサーを導入する場合は、そのインスタンスがボトルネックにならないように設計する必要がある。

それに対してELBを用いた場合、負荷に応じて自動的にスケールする設計になっている。

注意点として覚えておくべきこととして、このスケーリングが瞬時に完了するわけではない点が挙げられる。

そのため、数分程度で急激に負荷がかかるシーン、例えばテレビでサービスが取り上げられたり、リリース前の性能試験を行う場合などに「段階的な」スケールでは間に合わないことがある。

もし、このような急激な負担増(スパイク)が予想できる場合は、事前にELBプレウォーミングの申請をしておく。

その時間に合わせてELBがスケールした状態にすることが可能。

もう1つ、ELBの大きな利点としてヘルスチェック機能がある。

ヘルスチェックは、設定された間隔で配下にあるEC2にリクエストを送り、各インスタンスが正常に動作しているかを確認する機能。

もし以上なインスタンスが見つかった時は自動的に切り離し、その後正常になったタイミングで改めてインスタンスをELBに紐づける。

ヘルスチェックには下記の設定値がある。

・対象のファイル

・ヘルスチェックの感覚

・何回連続でリクエストが失敗したらインスタンスを切り離すか

・何回連続でリクエストが成功したらインスタンスを紐づけるか

もしWebサーバーだけでなく、DBサーバーまで正常に応答することを確認したい場合は、DBにリクエストを投げるファイルをヘルスチェックの対象ファイルにする。

また、短い時間で紐付けをしたい場合は、ヘルスチェックの間隔を短くする、成功とみなす回数を少なくするといった調整を行う。

Auto Scaling

Auto Scalingは、システムの利用状況に応じて自動的にELBに紐づくインスタンスの台数を増減させる機能。

インフラリソースを簡単に調達でき、そして不要になれば使い捨てできるクラウドならではの機能。

Auto Scalingは次のような項目を設定することで、自動的なスケールアウト/スケールインを実現する。

・最小のインスタンス数

・最大のインスタンス数

・インスタンスの数を増やす条件と増やす数

・インスタンスの数を減らす条件と減らす数

また、インスタンスを減らす際にどのインスタンスから削除するか、例えば「起動時間が最も過去となる古いインスタンスから削除」といった設定もできる。

Auto Scalingを利用することで、繁忙期やピーク時期はインスタンス数を増やし、閑散期や夜間のリクエストが少ないときはそれなりのインスタンス数でサービスを運用する、といったことができる。

常にリソース数を最適化でき、予想を超えるリクエストを処理できずにビジネスチャンスを逃す、サービスの人気が出ずにインフラリソースが余るといったことを減らせる。

さらに、Auto Scalingのメリットとしては、耐障害性を上げることができる点も挙げられる。

例えば、インスタンス数の最小、最大ともに2台に設定する。

このとき、片方のインスタンスに問題が発生した場合は、ヘルスチェックで切り離され、その後Auto Scalingの機能で新たに正常なインスタンスが1台作れられる。常に最小台数をキープし続けるため、知らないうちに正常なインスタンスが減って障害に繋がった、という危険を未然に防ぐことができる。

★Auto Scalingは、EC2の利用状況に応じて自動的にインスタンスの台数を増減させる機能で、リソースの最適化、耐障害性の向上をもたらす

スケーリングポリシー

Auto Scalingのスケーリング方法は、大きく3つに分類できる。

・動的なスケーリング

・予測スケーリング

・スケジュールスケーリング

頻繁に利用される動的なスケーリングには、さらに3つのスケーリングポリシーがある。

・簡易スケーリング

・ステップスケーリング

・ターゲット追跡スケーリング

簡易スケーリング

CPU使用率が70%を超えたらといったように、1つのメトリクスに対して1つの閾値を設定する。

最初期からあるスケーリング方法で、今は非推奨になっている。

ステップスケーリングで代用可能。

ステップスケーリング

ステップスケーリングは、1つのメトリクスに対して複数の閾値を設定する。

例えば、CPU使用率が50%を超えた場合、60%を超えた場合と、段階(ステップ)ごとの設定ができる。

このように複数の閾値を設定できるが、1つのみ閾値を設定することができる。

そのため、AWSとしては簡易スケーリングよりもステップスケーリングを推奨している。

ターゲット追跡スケーリング

1つのメトリクスに対して目標値を設定する。

例えば、「CPUの利用率を50%に」という目標値を設定すると、Auto Scalingグループ全体でCPI利用率が50%を維持できるように自動的に調整される。

ステップスケーリングのように細かく刻んで設定しなくても、AWS側がコントロールしてくれる。

今後は、このターゲット追跡スケーリングが主流になる見通し。

スケーリングをする際には、起動設定や起動テンプレートの設定が必要。

実際に手を動かしてみて、設定の仕方を習得する。

スケールアウトの猶予期間・ウォームアップ・クールダウン

システムのパフォーマンスや信頼性を高めるためには、Auto Scalingを使って需要に応じてインスタンス数を増減させる必要がある。

その際には、インスタンスの立ち上がり中に新たなインスタンスが立ち上がることを抑止する必要がある。

そうしないと、想定以上の台数になってしまう可能性がある。

AWSには、そのための機構がいくつかある。

それがスケールアウトの猶予期間・ウォームアップ・クールダウン。

猶予期間

最初にヘルツチェックを猶予期間。

ヘルスチェックは、Auto Scalingの管理対象下にあるインスタンスの動作をチェックして、異常が認められた場合は新しいインスタンスと置き換えられる。

インスタンスの起動時間やインスタンス内のプロセスの起動時間があるために、すぐにそのインスタンスが利用可能な状態になるわけではない。

その間にヘルスチェックでエラーが出続けると想定したスケーリング動作にならないため、一定期間ヘルスチェックをしないという猶予期間がある。

画面コンソールから作った場合の猶予期間はデフォルトで300秒(5分)。

ただし、CLIやSDKから作った場合はデフォルトが0秒のため注意が必要。

ウォームアップとクールダウン

猶予期間以外にも、ウォームアップとクールダウンというパラメータがある。

クールダウンの正式名称はスケーリングクールダウンという。

これはAuto Scalingが発動した直後に、追加でインスタンスの増減がなされるのを防ぐための設定。

猶予期間と混同されがちだが、猶予期間はヘルスチェックの猶予であり、クールダウンはインスタンスの増減のアクションの発動に対してのパラメータとなる。

なお、現在ではクールダウンは主に簡易スケーリングのための設定であり、それ以外のスケーリングポリシーの場合は、デフォルトの設定のまま調整しないで済むようになっている。

例えば、ステップスケーリングの場合、メトリクスに対して複数の閾値が設定できる。

そのためスケーリング動作中に別の閾値に達した場合には、クールダウンと関係なく反応するようになっているため。

ウォームアップはおおむねステップスケーリングにおいて差分でインスタンスを追加するために追加された機能。

CPUの利用率が50%のときに1台追加、70%のときに2台追加というポリシーが設定された場合を例に動作を確認する。

ウォームアップの操作のポイントは2つ。

1つ目のポイントは、ウォームアップ期間中には、そのアラームでのインスタンス追加はされない点。

2つ目は、ウォームアップ期間中に次のアラート(70%)が発動した場合、差分の台数が追加される点。

ウォームアップは、ステップスケーリングとターゲット追跡スケーリングポリシーに対応している。

その他のAuto Scalingのオプション

他にもAuto Scalingにはいくつかのオプションがある。

代表的なものとしてはライフサイクルフックと終了ポリシーの2つ。

ライフサイクルフック

ライフサイクルフックは、Auto Scalingグループによるインスタンスの起動時または削除時にインスタンスを一時停止してカスタムアクションを実行する機能。

例えば、起動時にデータを取得してきたり、削除時にログやデータの退避の処理を追加するといった用途で使える。

待機時間はデフォルトで1時間、最大で48時間まで設定できる。

終了ポリシー

負荷に応じてインスタンスを増やすことをスケールアウトという。

これに対して、負荷が下がってインスタンスを減らす場合はスケールインという。

Auto Scalingでスケールインの際にどのインスタンスを削除するかを決めるのが終了ポリシー。

デフォルトの終了ポリシーでは、インスタンスがAZに均等に配分されるように削除する。

2つのAZで2台・3台とインスタンスがある場合、3台あるAZのインスタンスを1つ削除させてAZ間で均等にさせるといった動作になる。

スケーリングポリシーやスケールアウトの猶予期間・ウォームアップ・クールダウン・終了ポリシーは、ELBの機能ではなく、Auto Scalingの機能。

ELBとAuto Scalingの機能を混同してしまうケースが多いため、それぞれの機能をしっかりと理解する。

終了ポリシー

・OldestInstance：最も古いインスタンスを削除

・NewestInstance：最も新しいインスタンスを削除

・OldestLaunchConfiguration：最も古い起動設定のインスタンスを削除

・ClosestToNextInstanceHour：次の課金時間に最も近いインスタンスを削除

・Default：AZ間の台数の均衡を保つようにインスタンスを削除

・OldestLaunchTemplate：最も古い起動テンプレートを使用するインスタンスを削除

・AllocationStratery：スポットまたはオンデマンドなどのインスタンスタイプの配分戦略に沿って削除

ELBとAuto Scalingを利用する際の設計ポイント

ELBとAuto Scalingを導入するときに気をつけたい2つのポイント。

1つ目はサーバーをステートレスに、つまり状態を保持しないように設計すること。

例えばファイルをアップロードする機能がある場合、アップロードされたファイルをインスタンス上に保持したとする。

この時、次のリクエストが他のインスタンスに振り分けられた場合、アップロードしたはずのファイルを参照できなくなってしまう。

また、Auto Scalingを有効にしていた場合、スケールインのタイミングでそのインスタンスが削除されてしまうかもしれない。

データはDBに格納しファイルはインスタンス外のS3に置くといった設計に変更し、このような事態を防ぐ。

ステートレスに設計するには、インフラ設計だけでなく、アプリケーション設計でも気をつけなればならない。

PJ全体としてステートレスに作る意識を持つように啓蒙することも、アーキテクトの役割だと言える。

もう1つは、AZをまたがってインスタンスを配置する設計にすべきだという点。

AWSではごくまれにAZ全体の障害が発生することがある。

そのときにインスタンスが1つのAZに固まっていると、すべてのインスタンスが利用できなくなり、結果としてサービス全体が停止してしまう。

もし4台のWebサーバーを用意するのであれば、たとえば2台はap-northeast-1aのゾーンに、もう2台はap-northeast-1cのゾーンに配置するようにする。

そうすることで、AZ障害が発生したとしても、縮退構成にはなるが、サービス全体の停止を避けられる。

このようにAWSでは「いかに単一障害点をなくすか」「部分の障害は起こり得ることを前提として設計する」という思想が非常に大切になってくる。

★「いかに単一障害点をなくすか」および「部分部分の障害は起こり得ることを前提に設計する」という思想が大切

ECS

ECSは、Dockerコンテナ環境を提供するサービス。

ECSが登場する前は、AWS上でDockerを導入するには、EC2上にソフトウェアを導入する必要があった。

この導入作業や継続したメンテナンス作業は人手で行う必要があり、特に多くのコンテナを運用する場合は骨が折れる作業だった。

ECSは、Docker環境に必要な設定が含まれたEC2インスタンスが起動し、その管理をサポートする。

骨の折れる前述の作業をAWS側に任せることができるため、開発者はアプリケーションの開発に集中できる。

ECSの特徴

まず、EC2インスタンス上で実行されるコンテナのことをTaskと呼び、EC2インスタンスのことはClusterと呼ぶ。

1つのCluster上で複数のTaskを実行することができる。

Cluster上で動作するTaskの定義はTask Definitionで行う。

Taskの役割ごとにTask Definitionを用意し、それをもとにClusterの上でTaskが起動する。

同じTaskを複数用意したい場面がある。

例えばWebサーバーTaskを複数用意し、ELBに紐づけるときなど。

そのような場面で用いるのがService。

Serviceでは、「Webサーバー用のTask DefinitionでTaskを4つ起動する」といった指定ができる。

もちろん、Auto Scalingを用いて動的にスケーリングする指定も可能。

また、Serviceを利用することで、Taskの更新をブルーグリーンデプロイメントで行うこともできる。

セキュリティ面の特徴としては、TaskごとにIAMロールを割り当てることが挙げられる。

EC2の場合は、IAMロールをインスタンス単位でしか割り当てられなかったが、ECSでは同じCluster上で起動するTaskごとに別のIAMロールを付与できる。

そのため、次のような権限管理も可能になる。

・Webサーバー用のTaskにはSQSへのSendMessage権限のみを付与する

・同じCluster上で動くバッチサーバーTaskには、SQSからのReceiveMessageとS3からのGetObjectの権限のみを付与する

★EC2インスタンス上で実行されるコンテナのことをTaskと言い、このEC2インスタンスのことをClusterと言う。1つのCluster上で複数のTaskを実行できる。Cluster上で動作するTaskの定義はTask Definitionで行う。

AWSにおけるその他のコンテナサービス

ECS以外にも、AWSには下記のコンテナサービスがある。

・AWS Fargate

・EKS

・ECR

ECSでは、Cluster用のEC2インスタンスが必要だった。

そのため、そのEC2インスタンス自体の管理、例えばAuto Scalingの設定などは利用者側で意識する必要があった。

AWS Fargateは、このEC2を使わずにコンテナを動かすことができるサービス。

現在、ECSでTask定義を作成するときは、起動タイプとしてEC2(従来のECS)かFargateかを選択できる。

Fargateを選択するとClusterの管理が必要なくなるので、ECSよりもさらにアプリケーション開発に集中できるようになる。

Fargateは各タスクに割り当てるCPUとメモリに応じて利用料が決まるという特徴がある。

Kubernetesは、コンテナ管理の自動化のためのオープンソースプラットフォーム。

従来、Kubernetesを利用するためにはマスター用のEC2インスタンスを複数台用意し、管理する必要があった。

EKSは、このマスターをサービスとして提供するサービス。

マスター用のEC2を管理する必要がなくなり、差別化を生む機能の開発により集中できるようになる。

Dockerを用いる場合、そのコンテナイメージをレジストリで管理する必要がある。

自前で運用する場合、レジストリ自体の可用性を高める設計が必要になる。

このレジストリをサービスとして提供するのがECR。

レジストリの管理をECRに任せることができる。

レジストリへのpush/pull権限をIAMで管理することも可能。

Lambda

AWS Lambdaは、サーバーをプロビジョニングしなくてもプログラムを実行できるコンピューティングサービスで、いわゆるサーバーレスアーキテクチャの中核を担う存在。

EC2をオンプレミス環境と比べた時に、リードタイムが短くなることがメリットの1つ。

それでもEC2上でソースコードを動かすには、インスタンスを作成し、各種ソフトウェアを導入する必要がある。

また、ELBやAuto Scalingの機能を使ってリクエストを負荷分散する設定をしたり、運用フェーズではEC2にパッチを当てたりといった作業は利用者側で行わなくてはならない。

Lambdaを用いるとソースコードの実行環境一式が提供されるため、利用者はソースコードを用意すればすぐにプログラムを実行できる。

また、リクエストの数に応じて自動的にスケールするため、処理に必要なサーバーの台数を考える必要もない。

サーバーを持たないため、パッチ当てなどの保守作業を行う必要がなく、利用者はインフラ管理の大部分をクラウドに任せることができる。

結果として、ビジネス的に価値のある機能の実装に開発リソースをつぎ込むことができる。

このようにサーバーを持たない構成をとることで、様々なメリットを享受できる。

Lambdaがサポートしているイベントと、よく使われるアーキテクチャパターン

Lambdaは、ソースコードをデプロイするだけでプログラムを実行できる環境を提供するサービス。

Lambdaを使うには、Lambda関数という単位で、実行するプログラムとその実行トリガーとなるイベントを事前に定義する。

そして、そのイベントが発生したタイミングでプログラムが実行される。

指定できるイベントの一例として、次のものが挙げられる。

・S3バケットにオブジェクトが追加されたとき/S3バケットからオブジェクトが削除されたとき

・DynamoDBテーブルが更新されたとき

・SNS通知が発行されたとき

・SESがメール受信したとき

・API GatewayへのHTTPSリクエストがあったとき

・CloudWatch Eventsによって定義されたスケジューリング実行

特に利用されることが多いアーキテクチャパターンはS3トリガー。

S3に画像がアップロードされたら、それをトリガーにLambda関数を起動する。

Lambda関数は対象となる画像を取得し、サムネイル用の画像を作成して別のS3バケットに追加する。

バッチサーバーを常駐させるのではなく、イベント駆動で特定の処理を行うアーキテクチャでLambdaの良さを活かしている例。

続いて、APIの提供をLambdaを利用して行うパターン。

API GatewayはリクエストのあったURIとHTTPメソッドの組み合わせで、呼び出すLambda関数を指定できる。

呼び出されたLambda関数はビジネスロジックを実行し、必要に応じてDynamoDBとデータをやり取りした上でAPI Gateway経由でレスポンスを返す。

APIリクエストのピーク時に自動スケールする構成にできるため、このパターンもよく用いられる。

最後に定期実行パターン。

CloudWatch Eventsと組み合わせることで、「毎時」や「火曜日の18時」といった形でLambdaの実行タイミングを指定できる。

例えば、1時間に1回外部のAPIから情報を取得するクローラーとしての利用や、定期的にSlackに何かしらの情報をつぶやくボットを実装する際に利用できる。

★Lambdaを利用するには、Lambda関数という単位で、実行するプログラムとその実行トリガーとなるイベントを事前に定義する

Lambdaがサポートしているプログラミング言語

様々なアーキテクチャの中核としてLambdaを利用することができる。

Lambdaでは2020年12月の時点で下記のプログラミング言語をサポートしている。

・Node.js

・Ruby

・PowerShell

・Python

・C#

・Java

・Go

明確にどの言語が向いている、向いていないというものはないが、Pythonでは初回のLambda起動までの時間が短くなる傾向がある。

逆にJavaでは、初回起動までの時間はかかるものの処理は速いという傾向がある。

そのため、機能要件や非機能要件、開発メンバーの利用経験などを鑑みて言語を選定すると良い。

Lambdaでは、利用する言語以外に下記の項目を設定する必要がある。

・割り当てるメモリ量

・タイムアウトまでの時間

・Lambdaに割り当てるIAMロール

・VPC内で実行するかVPCの外で実行するか

なお、LambdaのCPUパワーは割り当てたメモリ量によって決まる。

lambdaの料金体系

もう1つのLambdaの大きな特徴は、その料金体系。

Lambdaの料金体系は、リクエストの数と処理時間によって決まるリクエスト課金モデルになっている。

そのため、1時間に数回起動できればいいバッチや、どれくらリクエストがくるか予想できないAPIを構築する際などに、コスト最適な構成にすることができる。

Lambdaの特徴まとめ

・プログラムの実行環境を提供し、インフラの構築や管理にかける時間を減らせる

・リクエスト量に応じて自動的にスケールする

・リクエスト量や処理時間に応じた課金モデルが採用されている

まとめ

コンピューティングサービス

・仮想サーバーを提供するEC2、Dockerコンテナの実行環境を提供するECS、サーバーなしでプログラムの実行環境を提供するLambdaが、AWSにおけるコンピューティングサービスの中核を担う

・EC2を使うとサーバーインスタンスの個数や性能を柔軟に変更できるため、コスト削減や時間短縮が実現できる

・高負荷に耐えるためにEC2インスタンスのスペックを上げる対応をスケールアップと呼ぶ

・スケールアップには限界があり、単一EC2インスタンスでの運用ではそのインスタンスが単一障害点になる可能性がある

・EC2インスタンスを複数用意して、それらに負荷分散することで高負荷に耐える対応をスケールアウトと呼ぶ

・ロードバランサーのマネージドサービスであるELBは、スケールアウト時の負荷分散を担う

・Auto Scalingは、EC2の利用状況に応じて自動的にインスタンスの台数を増減させる機能で、リソースの最適化、耐障害性の向上をもたらす

・EC2インスタンス上で実行されるコンテナのことをTaskと言い、このEC2インスタンスのことをClusterと言う。1つのCluster上で複数のTaskを実行できる。Cluster上で動作するTaskの定義はTask Definitionで行う

・Lambdaを利用するには、Lambda関数という単位で、実行するプログラムとその実行トリガーとなるイベントを事前に定義する