雑記

Positive anything is better than negative nothing.

ElasticBeanstalk(弾性豆)

本日は弾性豆ことElasticBeanstalkについて勉強しました

 

AWS Elastic Beanstalk とは? - AWS Elastic Beanstalk

ドキュメント

 

アマゾン ウェブ サービス (AWS) は 100 以上のサービスで構成されており、各サービスは特定の領域の機能を提供します。幅広いサービスによって、AWS インフラストラクチャを柔軟に管理できますが、使用すべきサービスやそのプロビジョニング方法を理解するのは困難な可能性があります。

Elastic Beanstalk を使用すると、アプリケーションを実行しているインフラストラクチャについて知識を得なくても、AWS クラウドでアプリケーションのデプロイと管理を簡単に行うことができます。Elastic Beanstalk は、選択肢を狭めたり制御を制限したりすることなく、管理の複雑さを軽減します。アプリケーションをアップロードするだけで、Elastic Beanstalk は容量のプロビジョニング、ロードバランシング、スケーリング、およびアプリケーション状態モニタリングといった詳細を自動的に処理します。

Elastic Beanstalk は、Go、Java、.NET、Node.js、PHPPythonRuby で開発されたアプリケーションをサポートします。アプリケーションをデプロイすると、Elastic Beanstalk は選択されたサポートされるプラットフォームのバージョンをビルドし、1 つ以上の AWS リソース (Amazon EC2 インスタンスなど) をプロビジョニングしてアプリケーションを実行します。

Elastic Beanstalk コンソール、AWS Command Line Interface (AWS CLI)、または eb (Elastic Beanstalk 専用の高水準 CLI) を使用して、Elastic Beanstalk とやり取りできます。

 

f:id:kobushifactory:20210728170356p:plain

ワークフロー図

アプリケーションクリエート以外のところを自動でやってくれる。

ElasticBeanstalkコンソールで、アプリケーションを格納し、その他の設定(EC2インスタンスの数やELBは何を使うか、セキュリティグループはなど)を設定するとデプロイしてくれる。

また

バージョン管理もできる。

 

料金はかからない。当然だがEC2とかAWSのサービスの料金はかかる。ElasticBeanstalk自体はかからない。

 

・なぜElasticBeanstalkを使うの

基本的にアプリケーションというのはほとんどが同じ構成をしている。

ALB ASG EC2 DB S3

開発者はコードがランするかどうかに興味があり、その過程には興味がない

自動化できるならしてしまおう

ElasticBeanstalkは簡単にデプロイすることを手伝ってくれるし、しようと思えば複雑な設定も可能(ebextensions=ElasticBeanstalkのextensionや、カスタムプラットフォームを使う)

 

・構成

アプリケーション

アプリケーションバージョン

環境

 

・デプロイオプション

[ローリング更新とデプロイ] ページの [アプリケーションのデプロイ] セクションには、アプリケーションのデプロイの以下のオプションがあります。

  • [Deployment policy (デプロイポリシー)] - 以下のデプロイオプションから選択します。

    • [All at once (一度に)] - 同時にすべてのインスタンスに新しいバージョンをデプロイします。環境内のすべてのインスタンスは、デプロイが実行される間、短時間ですがサービス停止状態になります。

    • [Rolling (ローリング)] - バッチに新しいバージョンをデプロイします。デプロイフェーズ中、バッチはサービス停止状態になり、バッチのインスタンスによる環境容量への負荷を低減します。

    • [Rolling with additional batch (追加バッチによるローリング)] - バッチに新しいバージョンをデプロイしますが、デプロイ中に総容量を維持するため、インスタンスの新しいバッチをまず起動します。

    • [Immutable (イミュータブル)] - イミュータブルな更新を実行し、新しいバージョンをインスタンスの新しいグループにデプロイします。

    • [Traffic splitting (トラフィック分割)] - アプリケーションの新しいバージョンをインスタンスの新しいグループにデプロイし、受信クライアントトラフィックをアプリケーションの既存のバージョンと新しいバージョンとの間で一時的に分割します。

[Rolling (ローリング)] および [Rolling with additional batch (追加バッチによるローリング)] デプロイポリシーでは、以下を設定できます。

  • [Batch size (バッチサイズ)] - 各バッチでデプロイする一連のインスタンスのサイズ。

    Auto Scaling グループ (最大 100%) で EC2 インスタンスの総数の割合を構成するには、[Percentage (パーセント)] を選択するか、[Fixed (固定)] を選択して固定数のインスタンスを設定します (環境の Auto Scaling 設定の最大インスタンス数まで)。

[Traffic splitting (トラフィック分割)] デプロイポリシーでは、以下を設定できます。

  • [Traffic split (トラフィック分割)] - デプロイする新しいアプリケーションバージョンを実行している環境インスタンスに Elastic Beanstalk がシフトする受信クライアントトラフィックの初期の割合。

  • [Traffic splitting evaluation time (トラフィック分割評価時間)] - 初回のデプロイが正常に完了してから、デプロイする新しいアプリケーションバージョンにすべての受信クライアントトラフィックをシフトするまで、Elastic Beanstalk が待機する時間 (分単位)。

[Deployment preferences] セクションには、ヘルスチェック関連のオプションが含まれています。

  • [Ignore health check (ヘルスチェックの無視)] - バッチが [Command timeout (コマンドタイムアウト)] の時間内に正常な状態にならなかった場合に、デプロイがロールバックするのを防ぎます。

  • [Healthy threshold (ヘルシーしきい値)] - ローリングデプロイやローリング更新、イミュータブルな更新中に、インスタンスが正常と見なされるしきい値を引き下げます。

  • [Command timeout (コマンドタイムアウト)] - デプロイがキャンセルされるまで、または [Ignore health check (ヘルスチェックの無視)] が設定されている場合は次のバッチの処理に移るまで、インスタンスが正常な状態になるために待機する秒数。

All at Onceは、EC2インスタンスを一度止めて、それらに新バージョンをアップデートする

一番早く、追加のコストもかからないが、アプリケーションが少しシャットダウンしてしまう

 

Rollingは、例えば4つのインスタンスを使ったアプリケーションの時に

じゃあ2個のインスタンスをとめて新バージョンをインストールする

新バージョンに2個インスタンスがアップデートできたら、旧バージョンのインスタンスをまたアップデートする

Rollingの場合はアプリケーションはシャットダウンしないが、少し性能が落ちることになる

追加の費用はかからない

 

Rolling with additional batchは、4個の旧バージョンインスタンスは保持しつつ、2個インスタンスを新たに立ち上げ、新バージョンとする

新バージョンがアップデートできたら、それを旧バージョン2個に対してバッジ処理する

それが終わると、もう2個の旧バージョンインスタンスに対してさらにバッジ処理をする

旧バージョンインスタンスにすべてバッジ処理が終わったら新たに立ち上げていたインスタンスを終了する

この場合、インスタンスを2個追加で立ち上げているので追加費用がかかる

だが、アプリケーションの性能は落とさずにできる

 

immutableはさらに4個のインスタンスを立ち上げ、それらが新バージョンをインストールできたら、ALB等のトラフィックをそちらに変えて、旧バージョンインスタンスを終了する

この場合追加で4つ立ち上げているから追加費用が最もかかる

ただしアプリケーションの性能は全く落としていない

ロールバックが簡単である

Blue/Greenデプロイメントとの違いは、こちらがALB等のトラフィックを変更するというものに対し

Blue/GreenデプロイメントはROUTE53などのDNSサービスの加重ルーティングポリシーを利用し、加重を調整し、新バージョンがうまく稼働するかチェックするというもの

 

Traffic splittingは、トラフィックをALB等のELBを利用して分散する。これも例えば新バージョンに10%だけトラフィックを送付するなど。そうして新バージョンをモニターし、異常があれば、すぐ元のバージョンに戻すことができるというもの。

考え方としてはBlue/Greenデプロイメントに似てる。

 

Deploying applications to Elastic Beanstalk environments - AWS Elastic Beanstalk (amazon.com)

f:id:kobushifactory:20210728174241p:plain

超参考になる比較

 

・Blue/Greenデプロイメント

ElasticBeanstalkの機能ではないが、Blue/Greenデプロイメントも当然できる。

アプリケーションのバージョンを更新するときに AWS Elastic Beanstalk がインプレース更新を実行するため、アプリケーションはわずかな期間、ユーザーに利用不可になることがあります。Blue-Green Deployment を実行することで、このダウンタイムを回避できます。この場合、個別の環境に新しいバージョンをデプロイしてから、2 つの環境の CNAME を入れ替えて、すぐに新しいバージョンにトラフィックをリダイレクトします。 

 

・高度な設定 ebextensions

ウェブアプリケーションソースコードAWS Elastic Beanstalk 設定ファイル (.ebextensions) を追加することで、環境を設定し、環境に含まれる AWS リソースをカスタマイズできます。設定ファイルは、ファイル拡張子を .config とする YAML または JSON 形式のドキュメントです。この設定ファイルを .ebextensions というフォルダ内に配置してアプリケーションソースバンドルにデプロイします。

 

HTTPS

Elastic Beanstalk 環境用にカスタムドメイン名を購入して設定した場合は、HTTPS を使用することで、ユーザーがウェブサイトに接続する際の安全性を確保できます。ドメイン名を所有していない場合でも、開発およびテスト目的に自己署名証明書で、HTTPS を使用できます。HTTPS は、ユーザーデータやログイン情報を送信するいずれのアプリケーションにも必須です。

Elastic Beanstalk 環境で HTTPS を使用する最も簡単な方法は、環境のロードバランサーにサーバー証明書を割り当てることです。HTTPS を終了するようにロードバランサーを設定すると、クライアントとロードバランサーとの間の接続はセキュアになります。ロードバランサーと EC2 インスタンスとの間のバックエンド接続では HTTP が使用されるため、インスタンスの追加の設定は必要ありません。

 SSL証明書を使うことでHTTPSも可能。

ACMで管理できる。

 

・Cloudformationとの関係

ElasticBeanstalkは裏でCloudformationが動いている。

 

・ライフサイクルポリシー

ElasticBeanstalkではライフサイクルポリシーを設定できる。バージョンは1000までなので、古いものを削除するといった設定を日時ベースや容量ベースで設定可能。

 

・使用時の注意点

ELBは後から変更が不可能。なので変更したい場合は、同じ構成を用意してELBだけ変更し、その後ルーティングを変更するしかない。

 

また、ElasticBeanstalkのアプリケーションを消すと、それに付属しているサービスも消える。例えばデータベース等も消えてしまうので注意が必要。そのため、データベースを消したくない場合は、データベースのポリシーで削除不可の設定が必要となる。

 

・シングルDockerとマルチDocker

シングルの場合はECSを使わないが、ダブルの場合はECSを使う

 

・カスタムプラットフォーム

カスタムできる

ユースケース 使っている言語が対象外である 市販のソフトウェアを使いたい など

docker、ECS、ECR

今日はデベロッパーにおいて非常に重要だと思われる、dockerとECS周辺知識について学ぼうと思います。

新しいことを学ぶときってわくわくしますよね

 

・Dockerとは

Docker とは | AWS

Docker は、アプリケーションをすばやく構築、テスト、デプロイできるソフトウェアプラットフォームです。Docker は、コンテナと呼ばれる標準化されたユニットにソフトウェアをパッケージ化します。コンテナには、ライブラリ、システムツール、コード、ランタイムなど、ソフトウェアの実行に必要なすべてのものが含まれています。Docker を使用すると、どのような環境にもアプリケーションをすばやくデプロイおよびスケールでき、コードを実行することができます。

これがすごいところは、どんなOSでも機能するというところ

OSに関係なく同一の動作をする

 

またハイパーバイザ型との違いは

ハイパーバイザ型はまずホストOS、その上にハイパーバイザ、その上にゲストOSが必要で、それぞれのアプリケーションがそれぞれゲストOSを持つが

dockerの場合は、ホストOSの上にドッカ-デーモンが置かれ、その上にコンテナが置かれる。そのコンテナたちは、ドッカ-デーモンの上にたくさん置くことができ、ゲストOSを必要としない。共通のドッカ-デーモンの上に多数のコンテナという配置になる。

 

また優れている点として、イメージを利用して、パーツをすぐにビルドできる

例えば、webサーバーのapachemysqlなど様々なサービスがイメージ化されていて、利用者はコンテナにそのイメージを格納するだけで、そのサービスが使えるようになる。

Linuxでいちいちコードを入力して、apacheサーバーを立ち上げる

とかそういう煩わしいことがいらなくなる

 

イメージはdockerhubというサイトで検索して利用できる

Docker Hub

また、ECRを使ってプライベートにイメージを保存、利用もできる

 

・ECS

Amazon Elastic Container Service とは - Amazon Elastic Container Service

ECSはAWSでdockerを使うサービス

 

クラスタ

Amazon ECS クラスターは、タスクまたはサービスの論理グループです。タスクとサービスは、クラスターに登録されているインフラストラクチャで実行されます。

 クラスターのAutoscaling

Amazon ECS クラスターの Auto Scaling を使用すると、クラスター内の Amazon EC2 インスタンスをスケールする方法をより詳細に制御できます。Auto Scaling グループキャパシティープロバイダーを作成するときにマネージドスケーリングを有効にすると、Amazon ECS は、キャパシティープロバイダーの作成時に使用される Auto Scaling グループのスケールインおよびスケールアウトアクションを管理します。代わりに、Amazon ECS は指定したターゲットキャパシティーの値に基づいて、ターゲット追跡スケーリングポリシーを使用して AWS Auto Scaling スケーリングプランを作成します。次に、Amazon ECS は、このスケーリングプランを Auto Scaling グループに関連付けます。

キャパシティープロバイダーでは例えば、CPU使用率を70%を超えたら、新たなクラスターを作成する というようなことができる

タスク定義

Amazon ECS で Docker コンテナを実行するには、タスク定義が必要です。タスク定義で指定できるパラメータの一部を次に示します。

  • タスクの各コンテナで使用する Docker イメージ

  • 各タスクで、またはタスク内の各コンテナで使用する CPU とメモリの量

  • 使用する起動タイプ。この起動タイプにより、タスクをホストするインフラストラクチャが決定される

  • タスクのコンテナで使用する Docker ネットワーキングモード

  • タスクで使用するログ記録設定

  • コンテナが終了または失敗した場合にタスクを実行し続けるかどうか

  • コンテナの開始時に実行するコマンド

  • タスクのコンテナで使用するデータボリューム

  • タスクが使用する IAM ロール

→まずタスクの定義が必要となる。コンテナ内のタスクを定義する。例えばwebサーバーが必要ならばapache、CPUは1000、メモリ1GB、EC2で起動、などは必須で決めないといけない。

タスクボリューム

Amazon ECS は、コンテナに対して以下のデータボリュームオプションをサポートします。

  • Amazon EFS ボリューム — Amazon ECS タスクで使用するためのシンプルかつスケーラブルで、永続的なファイルストレージを提供します。Amazon EFS を使用すると、ストレージ容量が伸縮自在になり、ファイルの追加および削除時に自動的に伸縮されるようになります。アプリケーションは、必要なときに必要なストレージを持つことができます。 Amazon EFS ボリュームは、Fargate または Amazon EC2 インスタンスでホストされるタスクでサポートされます。 詳細については、Amazon EFS ボリューム を参照してください。

  • Amazon FSx for Windows File Server ボリューム — フルマネージド Microsoft Windows ファイルサーバーを提供し、完全にネイティブの Windows ファイルシステムによってバックアップされます。Amazon ECS と共に Amazon FSx for Windows File Server を使用する場合、永続的、分散、共有、静的なファイルストレージで Windows タスクをプロビジョニングできます。詳細については、Amazon FSx for Windows File Server ボリューム をご参照ください。

  • Docker ボリューム — ホストの Amazon EC2 インスタンスで /var/lib/docker/volumes に作成される Docker マネージドボリューム。Docker ボリュームドライバー (プラグインとも呼ばれる) は、ボリュームを外部ストレージシステム (Amazon EBS など) と統合するために使用します。組み込みの local ボリュームドライバーまたはサードパーティーのボリュームドライバーを使用できます。Docker ボリュームは、Amazon EC2 インスタンスでタスクを実行する場合にのみサポートされます。Windows コンテナでは、 ドライバーの使用のみサポートされます。Docker ボリュームを使用するには、タスク定義で を指定します。詳細については、Docker ボリューム を参照してください。

  • バインドマウント — Amazon EC2 インスタンスや AWS Fargate など、ホスト上のファイルまたはディレクトリがコンテナにマウントされます。 バインドマウントのホストボリュームは、Fargate または Amazon EC2 インスタンスでホストされているタスクでサポートされています。 詳細については、バインドマウント を参照してください。

 →覚えるべき考え方は3つ。EBS、EFS、バインドマウント。EBSの場合は、EC2インスタンスにアタッチすることになる。Autoscalingでコンテナを新たに立ち上げた際に、元のコンテナのEBSとは異なるEBSとなるのでデータが共有されない。

→対して、EFSを使った場合はECSタスクorFargateタスクにマウントをする。コンテナ間でデータが共有されるため、Autoscaling等に適しているといえる。またEFSなので高可用性がある。

→バインドマウントは

バインドマウントでは、ホスト (Amazon EC2 インスタンスや AWS Fargate など) 上のファイルまたはディレクトリがコンテナにマウントされます。 バインドマウントは、Fargate インスタンスAmazon EC2 インスタンスの両方でホストされているタスクでサポートされています。 デフォルトでは、バインドマウントは、それらを使用してコンテナのライフサイクルに関連付けられます。タスクが停止するなど、バインドマウントを使用するすべてのコンテナが停止すると、データが削除されます。Amazon EC2 インスタンスでホストされているタスクの場合、タスク定義で host 値とオプションの sourcePath 値を指定することにより、データをホスト Amazon EC2 インスタンスのライフサイクルに関連付けることができます。詳細については、Docker ドキュメントの Using bind mounts を参照してください。

バインドマウントの一般的なユースケースは以下のとおりです。

  • 1 つ以上のコンテナにマウントするための空のデータボリュームを提供する。

  • 1 つ以上のコンテナにホストデータボリュームをマウントする。

  • ソースコンテナのデータボリュームを、同じタスク内の他のコンテナと共有する。

  • Dockerfile から 1 つ以上のコンテナにパスとその内容を公開する。

Use bind mounts | Docker Documentation

【Docker】第5回 マウントについて(bind)/札幌のAI・IoT・システム開発|ITイノベーション/最先端技術|パブリックリレーションズ

→バインドマウントのユースケースがあまり分かっていません、、

デベロッパーの問題を解きながら確認していきたいと思います。

 

・サービスのAutoscaling

Auto Scaling は、Amazon ECS サービスの必要タスク数を自動的に増減させる機能です。Amazon ECS は Application Auto Scaling サービスを活用してこの機能を提供します。詳細については、Application Auto Scaling ユーザーガイドを参照してください。

→ターゲット追跡スケーリングポリシー、ステップスケーリングポリシー、スケジュールに基づくスケーリング

 

ロールバックとBlue/Greenデプロイメント

ロールバックは随時新しいものに更新していく EC2インスタンス等を

Blue/Greenデプロイメントは新しいものを用意して、稼働させてから、古いものを落とす。一瞬のサービスの停止も許さないという感じ。

 

・タスクの配置戦略

タスク配置戦略は、タスク配置またはタスクの終了でインスタンスを選択するためのアルゴリズムです。タスクの実行時または新しいサービスの作成時に、タスク配置戦略を指定できます。タスク配置の戦略は、既存のサービスに対しても更新できます。

binpack

タスクはコンテナインスタンスに配置され、未使用の CPU またはメモリを最小にします。この戦略は、使用中のコンテナインスタンスの数を最小限に抑えます。

この戦略が使用され、スケールインアクションが実行されると、Amazon ECS は、タスクが終了した後にコンテナインスタンスに残されるリソース量に基づいてタスクを終了します。タスクの終了後に使用可能なリソースが最も多く残るコンテナインスタンスが、そのタスクを終了させます。

random

タスクはランダムに配置されます。

spread

タスクは指定された値に基づいて均等に配置されます。有効な値は instanceId (または同じ効果を持つ host)、または attribute:ecs.availability-zone などのコンテナインスタンスに適用される任意のプラットフォームまたはカスタム属性です。

サービスタスクはそのサービスからのタスクに基づいて分散されます。スタンドアロンタスクは、同じタスクグループからのタスクに基づいて分散されます。タスクグループの詳細については、タスクグループ を参照してください。

spread 戦略が使用され、スケールインアクションが実行されると、Amazon ECS は、アベイラビリティーゾーン間のバランスを維持するタスクを選択して終了します。アベイラビリティーゾーン内では、タスクはランダムに選択されます。

 

→これらの戦略は組み合わせも可能。

 

・ALB

ALBを使用することで動的マッピングポートが可能になる。CLBは静的のみ。

Amazon ECS の動的ポートマッピングをセットアップする

同一コンテナで複数タスクが実行可能であるが、例えばapacheサーバーを複数入れたときに、apacheサーバーにホストポートを8080と設定すると、2つめのapacheサーバーに8080を設定することができなくなるため、実質的に2つ以上の同一タスクが行えなくなる。

その際にALBの動的ポートマッピングを使用する。ALBに属するセキュリティグループのトラフィックをすべて許可する設定を行っておき、ポートもすべてのポートを使用可にしておく。そうするとALBがランダムでポートをapacheサーバーに振り分けることで、同一コンテナ内でも複数の同一のタスクを動かすことができる。

 

・ECR ログイン CLIにて

aws ecr get-login-password --region region | docker login --username AWS --password-stdin aws_account_id.dkr.ecr.region.amazonaws.com

 

・Fargate

ECSをサーバーレスでできますよというもの。EC2のプロビジョニングがいらなくなる。

【かなり大事】CLIの際の認証情報の処理される順番とベストプラクティス

 の設定AWS CLI - AWS Command Line Interface 

AWS CLIで使える認証情報とオプションの設定方法まとめ | DevelopersIO

 

CLIの認証情報が処理される順番がある

 

comand line option    --region --output --profile

Environment variables 環境変数

CLI credential file    aws configure

CLI configuration file    aws configure

Container credential   ECS tasks

Insutance profile credentials

 

 

この順番

そしてこれはSDKの場合もほぼ同じ

 

そしてベストプラクティス

・コードの中にAWS認証情報を直接書くな

・認証情報チェーンから継承した認証情報を使え

AWS内で完結するサービスならIAMroleを使え

EC2インスタンスならEC2インスタンスロール

ECSタスクならECSロール

LambdaならLambdaロール

AWS外なら環境変数を使え

 

 

 

 

 

 

 

 

【小ネタ】EC2インスタンスに対するUnauthorizedOperationエラー メタデータ GetSessionToken

EC2 インスタンスの起動時の UnauthorizedOperation エラーを解決する

 

このエラーはEC2インスタンスに対する適正なIAMroleが付与されていないですよ

というエラー

 

AWS コマンドラインインターフェイス (AWS CLI) を使用してメッセージをデコードします。この暗号解析で、認証失敗に関する詳細がわかります

 

Launch Failed - You are not authorized to perform this operation. Encoded authorization failure message: 4GIOHlTkIaWHQD0Q0m6XSnuUMCm-abcdefghijklmn-abcdefghijklmn-abcdefghijklmn

 

エラーメッセージ例

丁寧にencodeしてね。と教えてくれてます。

 

$ aws sts decode-authorization-message --encoded-message encoded-message

の後に

さきほどのエラーメッセージの暗号化されている部分を入力

$ aws sts decode-authorization-message --encoded-message encoded-message 4GIOHlTkIaWHQD0Q0m6XSnuUMCm-abcdefghijklmn-abcdefghijklmn-abcdefghijklmn

 

こういうことですね

 

{ "DecodedMessage": "{\"allowed\":false,\"explicitDeny\":false,\"matchedStatements\":{\"items\":},\"failures\":{\"items\":},\"context\":{\"principal\":{\"id\":\"ABCDEFGHIJKLMNO\",\"name\":\"AWS-User\", \"arn\":\"arn:aws:iam::accountID:user/test-user\"},\"action\":\"iam:PassRole\", \"resource\":\"arn:aws:iam::accountID:role/EC2_instance_Profile_role\",\"conditions\":{\"items\":[{\"key\":\"aws:Region\",\"values\":{\"items\":[{\"value\":\"us-east-2\"}]}}, {\"key\":\"aws:Service\",\"values\":{\"items\":[{\"value\":\"ec2\"}]}},{\"key\":\"aws:Resource\",\"values\":{\"items\":[{\"value\":\"role/EC2_instance_Profile_role\"}]}}, {\"key\":\"iam:RoleName\",\"values\":{\"items\":[{\"value\":\"EC2_instance_Profile_role\"}]}},{\"key\":\"aws:Account\",\"values\":{\"items\":[{\"value\":\"accountID\"}]}}, {\"key\":\"aws:Type\",\"values\":{\"items\":[{\"value\":\"role\"}]}},{\"key\":\"aws:ARN\",\"values\":{\"items\":[{\"value\":\"arn:aws:iam::accountID:role/EC2_instance_Profile_role\"}]}}]}}}" }

 

そうするとデコードされたコードが出力される。

IAMroleの文なのでJSON形式となっている。

 

前述のエラーメッセージは、リクエストが RunInstances を呼び出さなかったことを示します。これは、AWS-User が iam:PassRole アクションを arn:aws:iam::accountID:role/EC2_instance_Profile_role に対して実行するアクセス許可がないためです。

と読み取れるらしい。

 

メタデータ

EC2インスタンスメタデータに関して

インスタンスメタデータサービスの設定 - Amazon Elastic Compute Cloud

 

EC2インスタンスに関する様々な情報を知りたいとき

マネジメントコンソールから見れるものもありますが

メタデータを使うと、調べることができる

 

そしてIAMroleをEC2インスタンスが必要とせずに調べることができる

 

 

・GetSessionToken

GetSessionToken のアクセス権限 - AWS Identity and Access Management

 CLIでMFAを使う際に必要となるAPI

 

 

 

【小ネタ】redisのクラスターモードが有効の場合と無効の場合 サービスクォータ(制限) エクスポネンシャルバックオフ

レプリケーション: Redis (クラスターモードが無効) と Redis (クラスターモードが有効) の比較 - Amazon ElastiCache for Redis

 

クラスターモードが無効の場合

一つのプライマリノードと、0~5個のレプリカノードからなる一つのシャード(プライマリノードとレプリカノードの集まりこと)からなる。

 

クラスターモードが有効の場合

500個のシャードを持てる

データのパーティションができる

またノードによってシャード数が決まる

プライマリとレプリカノードを持つ場合は250シャードまで

プライマリとレプリカノードを5個持つ場合はシャード数は83までとなる。

ノード数×シャード数が500以下じゃないといけない

 

 

比較

スケーリングはレプリカノードの数を増やすことで行える

無効の場合はレプリカノードは最大で5個までしかスケーリングできない

 

クラスターが有効の場合はシャードを増やせるので、さらにスケーリングできる

ただし、クラスターを有効にする場合はデータを分けて、それぞれのシャードで処理をすることになる

 

 

 

感想

データを分割するのが要件に合わない場合は無効

データを分割するのがオッケーな場合は、シャードを増やせてノードも多く扱える有効にした方がいいってことでしょうか?もちろんコスト等は考えながら

 

 

・サービスクォータ

サービスエンドポイントとクォータ - AWS 全般のリファレンス

以前はサービスの制限といわれていた

AWSのサービスには制限がある

API rate limits DescribeInstances API for EC2が100cells per secondsであるとか

・Service Quotas S3のバケット数は100までだとか

こういうのがある

これはAWSに申請して制限を緩めることができる場合もある

 

 

・エクスポネンシャルバックオフ

でのエラー再試行とエクスポネンシャルバックオフAWS - AWS 全般のリファレンス

指数関数的バックオフ

特定のリクエスト中にエラーになった際に、再試行をするよというもの

エクスポネンシャルバックオフの背後にある考え方は、連続したエラー応答の再試行間の待機時間を徐々に長く使用することです。最大遅延間隔と最大再試行回数を実装する必要があります。最大遅延間隔と最大再試行回数は、必ずしも固定値であるとは限らず、実行されるオペレーション、およびネットワークレイテンシーなどのその他のローカル要因に基づいて設定する必要があります。

またその際に再試行をする時間を指数関数的に増やしていくというもの

 

SDKには自動再試行ロジックが実行されている。

 

SDKじゃない場合はコードを書く必要があるよ

AWS SDKを使用していない場合は、サーバー (5xx) またはスロットリングエラーを受け取った元のリクエストを再試行する必要があります。ただし、クライアントエラー (4xx) は、再試行する前にリクエストを修正して問題を解決する必要があることを示します。

とのこと。

 

ElasticCache キャッシュとキャッシュ戦略について 疑問点あり

キャッシュの際に考えること

 

・そのキャッシュは古くないですか?一貫性がありますか?

・キャッシュは効果的ですか?

・データの変化が遅いとき いくつかのキーのみが頻繁に変わるとき→効果的かもしれない

・データが急速に変わるとき 大きなキーが頻繁に変わるとき→効果的ではないかもしれない

・キャッシュのためにデータが構造化されていますか?

 

最も大事なこと

キャッシュ戦略はどうしますか?

https://docs.aws.amazon.com/ja_jp/AmazonElastiCache/latest/mem-ug/Strategies.html

 

キャッシュ戦略は2つある

 

遅延読み込み

アプリケーションとDBがあり、その間にキャッシュサービスがある。

アプリケーションからまずキャッシュにデータリクエストを送る

キャッシュにあればデータを返す(キャッシュヒット)

キャッシュになければ(キャッシュミス)DBにデータをリクエストする

DBはアプリケーションにリクエストを返し

アプリケーションはキャッシュにその情報を書き込む(キャッシュを更新)

 

 

利点

必要なデータのみキャッシュされるため、キャッシュがデータでいっぱいになることがない

ノード障害がクリティカルではない

欠点

キャッシュミスの場合、トリップが多くなる(1回で済むのが3回になるためレイテンシーあり)

データが古くなる可能性あり

 

次に書き込みスルー

書き込みスルーはDBが更新されるとキャッシュも更新するというもの

利点

キャッシュのデータが古くならない

書き込みペナルティ この場合はDBに書き込むと、キャッシュも更新(書き込む)するので、2回書き込みを行うことになる

しかし、読み取りペナルティ(遅延読み込みの場合)は1回のキャッシュミスに対し、3回の動作が必要であったため、書き込みペナルティのほうが動作の回数が少ない

また、一般的にユーザーは書き込みことは時間がかかると分かっているので、書き込みペナルティに関して寛容である

欠点

ノード障害等で欠落データが起こる可能性がある これは遅延読み取りを利用することで乗り越えられる

キャッシュが多い キャッシュの量が多くなってしまう。そのためTTLの設定をすることが望ましい。

 

 

まとめ

遅延書き込みは簡単に設定ができ、多くの場合非常に役に立つことがおおい

書き込みスルーは少し手がかかる 遅延書き込みよりも上級の設定となる

これらを組み合わせ、またTTLを効果的に設定することがキャッシュでは大事である

 

 

 

疑問点

遅延読み込みはノード障害時にクリティカルではない

書き込みスルーはノード障害時にデータの欠落が起こる

?????????となりました

 

遅延読み込みは、アプリケーションからキャッシュに対してキャッシュミスとなった場合だけキャッシュに対して新たなデータを書き込む

書き込みスルーはアプリケーションも関係なく、DBが更新されたら、キャッシュも書き込む

ってことだと思うんですが、ノード障害でなぜ片方がクリティカルでなく、もう片方がデータの欠落が起こるのでしょうか、、、?

 

分からないので保留です

AWSデベロッパーアソシエイト試験 一つの仮説

こんにちは。拳です。

AWSデベロッパーアソシエイトの勉強をしています。

あまりお金をかけずに勉強をしたいなという気持ちがあり、模試を解いて、分からないことを調べて、また模試を解いて、、、

という勉強方法を取ろうかなと思っていました。

 

ちなみにこのudemyの模試を買いました。

AWS 認定デベロッパー アソシエイト模擬試験問題集(5回分325問) | Udemy

最初に一回目をやってみたのですが、本当に全然分からなくて泣きそうになりました。

正答率は41%でした。

クラウドラクティショナーではAWSの公式デジタル講義

SAAではudemyの講義を受講しました。

 

デベロッパーでは講義を受けないで自分で調べながら勉強をしてみよう

という気持ちがあり、まだ講義を買ってないのです。

 

ですが、模試を解いて、あまりにも分からないことがありすぎて、正直どれから手をつけていいか分からない状態になっています。

 

ここで一つの仮説が思いつきました。

講座の模試評価では、「難しすぎる」という声が多く

また、講座の模試自体にも「難しく作っています」と書いてあります。

「もしかしてudemyの模試が難しすぎるだけで、公式の模試を解いてみたら意外と分かるんじゃないか。公式の模試が解けるようであれば、+αの勉強で受かるし、公式の模試も分からないようであれば、そこで初めてudemyの英語版の講義を受講するのも、費用対効果ではいいのでは」

と考えました。

 

ということで公式模試を受けてきます。

 

 

 

追記

 

公式模試は55%の得点率でした。

やはり、そこまでマニアックなことは聞かれなかった印象を持ちました。

 

ということで、「先達が情報をまとめてくれているなら、それに乗っかっちゃおう」の精神でudemyの講義がある講座をポチりました。

費用をケチって、もし試験に落ちたら、試験代がさらにかかってしまうので、、、

試験代高いですからね、、、、

いまやってますが、一人だと絶対にたどり着かないであろう情報を教えてくれて、そしてそれをもとにドキュメントを調べるといういい流れになっています。

面白い。