aws saaの勉強
あかさたなAWS Elastic Beanstalkについて
あかさたな
あかさたなAWS Elastic Beanstalk は、AWS でウェブアプリケーションを立ち上げて稼動させるのに最も速い方法です。アプリケーションのコードをアップロードするだけで、リソースのプロビジョニング、ロードバランシング、オートスケーリング、モニタリングなどの細かい作業はサービスが自動的に処理します。
あかさたなデプロイが簡単、監視もしてくれる、ロードバランシングとオートスケーリングもしてくれる
っていうマネージドサービス
パッチも適用してくれるらしい
→webアプリの開発に注力することができる（インフラのことを考える必要が少ない）
あかさたなAWS Elastic Beanstalk で追加料金は発生しません。アプリケーションの保存、実行に必要な AWS リソース (EC2 インスタンス、S3 バケットなど) に対してのみ料金が発生します。実際に使用した分に対してのみ料金が発生します。最低料金や前払いの義務はありません。
beanstalk自体の料金は発生しないのは驚き
あかさたな
AWS Elastic Beanstalkの裏側ではEC2インスタンスが生成されますが、そのEC2インスタンスがリソースを持て余して『リソースの無駄』が発生することがあります。
例えば「Dockerプラットフォーム」を利用している場合、AWS Elastic Beanstalkでは1台のEC2インスタンスに対して1コンテナが立ち上がります。もし1つのコンテナがリソースをそんなに使わない場合はリソースを効率的に利用するために1台のEC2インスタンスに対して複数のコンテナを立ち上げる方が無駄のないリソース利用が出来ます。
Amplify同様、作りこみにくいというデメリットがあるのでエンタープライズな実プロジェクトで使うことはほとんどありませんが、試験向けにはデプロイ手法がよく聞かれるので知っておいて損はありません。
デメリットはこんな感じかな...
個人開発とか小規模のものだったら使う価値はありそう
あかさたなECS/EKS/ECRについて
あかさたなECSとEKSはそれぞれコンテナ環境を運用するサービス
- ECS : Docker、使用可能なコンピューティングサービスはEC2, Fargate
- EKS：k8s、使用可能なコンピューティングサービスはEC2だけ
ECRはコンテナイメージのアップロード、管理をしてくれるサービス
あかさたな
あかさたな
ecrに登録されているイメージはECS、EKSだけでなくオンプレでも使うことが可能である
あかさたな- タスク：EC2,Fargate上で実行されるコンテナを管理する単位
- サービス：複数のタスクをまとめて管理する単位（サービス内で4つのタスクを実行する、1つ落ちた場合は復旧するみたいな）
- クラスター：タスクまたはサービスをまとめて管理する単位
タスク定義
- 実行するコンテナイメージ
- CPUやメモリのスペック
- タスクロール（IAMロール）
あかさたなEKSでポッド数を自動的に増減させる方法
- Horizontal Pod Autoscaler (HPA)を使用
- CPU利用率やメモリ使用量に応じてポッド数を増減させる
- Metrics Serverを導入
- HPAで使用するメトリクスを収集する
あかさたなEC2について
あかさたなコンピューティングサービス
あかさたな基盤について
- マルチテナンシー：普通のやつ
- ハードウェア占有インスタンス
- Dedicated Hosts
あかさたなハードウェア占有インスタンスとDedicated Hostsの違い
ハードウェア占有インスタンス
ハードウェア専有インスタンスとは、単一の AWS アカウント専用のハードウェア上で動作する EC2 インスタンスです。つまり、ハードウェア専有インスタンスは、それらのアカウントが単一の支払者アカウントにリンクされている場合でも、他の AWS アカウント に属するインスタンスからホストハードウェアレベルで物理的に分離されています。ただし、ハードウェア専有インスタンス は、同じ AWS アカウント に属する、ハードウェア専有インスタンスではない他のインスタンスとはハードウェアを共有できます。
Dedicated Hosts
専有ホストは、インスタンスの配置を可視化および制御し、ホストアフィニティをサポートします。つまり、特定のホストでインスタンスを起動して実行でき、インスタンスが特定のホストでのみ実行されるようにできます。詳細については、「Amazon EC2 専有ホストの自動配置とホストアフィニティ」を参照してください。
あかさたなつまり、ハードウェア占有インスタンスは、インスタンスが配置されるホストに他のAWSアカウントに属するインスタンスが存在しないことを保証してくれるもの
Dedicated Hostsはインスタンスを配置する時にホストを指定することが可能なもの
Dedicated Hostsの方が加えられる制限が大きい
ハードウェア占有インスタンスは他組織とホストを共有したくない時に使って、Dedicated Hostsは既存ライセンスの持ち込み（BYOL）を行いたい時などに使う
あかさたなユーザーデータ
- インスタンス起動時に実行されるbashコードなどを指定できる（ブートストラップ）
あかさたなストレージ
- インスタンスボリューム：停止、終了したらデータ削除される。無料
- EBS：停止、終了しても削除されない。S3にスナップショットを保存する。有料。
- EFS：サーバーレスで完全に伸縮自在なファイルストレージ
あかさたなあるEC2インスタンスのAMIを作成→AutoScalingで増やすみたいな構成の時
EC2にアタッチされているEBSボリュームをルートボリュームとして設定することでEBSのデータも複製することが可能
あかさたなAPI Gatewayについて
あかさたな
あかさたなAmazon API Gateway を利用すれば、デベロッパーは規模にかかわらず簡単に API の作成、公開、保守、モニタリング、保護を行えます。
API Gateway では、トラフィック管理、CORS サポート、認可とアクセスコントロール、スロットリング、モニタリング、API バージョン管理など、最大数十万規模の同時 API コールの受け入れと処理に伴うすべてのタスクを取り扱います。
お支払いいただくのは、受け取った API 呼び出しと送出したデータ量の分だけです。
あかさたな利点
- 効率的な API 開発：複数のバージョンのAPIを管理することが可能
- 規模に応じたパフォーマンス：CloudFrontと相性〇
- 大規模なコスト削減：APIリクエスト単位で段階的に課金（max 0.90USD/100万リクエスト）
- 簡単なモニタリング：ダッシュボードで監視することが可能
- 柔軟なセキュリティ管理：IAM, Cognitoを使うことで認証を管理することが可能
- RESTful API オプション：HTTP API or REST APIを作成可能
あかさたな
HTTP APIとは
- 機能を絞る代わりに、REST APIに比べて低コスト低レイテンシで実現できるAPI
- 呼び出し先はLambdaプロキシ、もしくはHTTPプロキシのみ設定可能
- 認証はOpenID Connect、OAuth2.0のJWTでの認証のみサポート
あかさたなLambdaについて
あかさたなLambda関数はLambda専用のセキュアなVPCに配置される
このLambda専用のVPCからは、インターネットにのみアクセスすることが可能である
そのためパブリックサブネット内のAWSリソースにはインターネット経由でアクセス可能であるが、プライベートサブネット内のAWSリソースへのアクセスはできない。
直接AWSリソースにアクセスさせたい場合は、VPCアクセスの設定を行うことでLambdaがHyperplane Elastic Network Interface（ENI）を作成し、ENI経由でアクセスすることが可能となる
ENIはサブネット毎に作成される
ただしENIを作成したLambdaはインターネットへ直接アクセスすることができなくなる
（サブネット内のNATにアクセスさせることでアクセスすることは可能）
あかさたな
あかさたなSQSについて
あかさたなキューの種類
- 標準キュー
- 無制限の数の1秒当たりのトランザクションをサポート
- 順序はベストエフォート
- 少なくとも1回はメッセージが配信され、重複することもある
- FIFOキュー
- 1秒当たりバッチ処理なしで300件、バッチ処理で3000件、高スループットモードだと7000件（バッチ：最大10件、256KBのメッセージをまとめて送れる）
- 順序が厳密に保持される（FIFO）
- メッセージの重複は起きない
厳密にしたい場合はFIFO、高スループットを求めるときは標準って感じかな？
あかさたなメッセージの取得方法について
- ショートポーリング
- ロングポーリング
キュー内にメッセージが存在しない時の挙動が異なる。
ロングの場合は、設定されたタイムアウトのギリギリまでメッセージを返さない、ショートはすぐ返す
→ショートの場合はAPIの呼び出し回数が多くなる。基本的にはロングにした方がよい。
例外として、複数のキューを1つの処理で扱うときなどは、すぐに次のキューを見に行った方が良いため、ショートが使われる。
あかさたなセキュリティについて
アクセスはIPアドレスや時刻で制御することが可能
また、KMSで管理された鍵を使って、メッセージの内容を暗号化することも可能。
あかさたな可視性タイムアウトについて
キュー内のメッセージは削除指示を受けた場合に削除される。
そのため、1つのリソースがメッセージを受け取って処理している間に、他のリソースが同じメッセージを受け取ってしまうという懸念がある。
それを解決するため、一定期間はそのメッセージを受け取ることができないようにしている。
デフォルトは30秒、最大12時間。
あかさたなメッセージの配信遅延について
- 遅延キュー
- すべてのメッセージで、メッセージが追加されてから取得できるまでの遅延時間を生じさせる
- メッセージタイマー
- 個別のメッセージで、メッセージが追加されてから取得できるまでの遅延時間を生じさせる
あかさたなSQS + Lambda
LambdaのトリガーにSQSを設定することで、LambdaがSQSをポーリングしてくれる
あかさたなRDS Proxyについて
あかさたな会社の人に聞いた話
Lambdaから直接RDSに書き込むようにすると、Lambdaごとにコネクションを貼っちゃう
RDSのコネクション数は上限が決まってるから、Lambdaが増えすぎちゃうと他からアクセスできなくなっちゃう
Lambda -> RDS Proxy -> RDS にすることで、コネクションを制御することができる
あかさたな
最新のサーバーレスアーキテクチャに構築されたアプリケーションなどのアプリケーションの多くは、データベースサーバーへの接続を多数開くことができます。このとき、データベース接続の開閉が高頻度で実行されて、データベースメモリやコンピューティングリソースを消耗する可能性があります。
Amazon RDS Proxy では、アプリケーションがデータベースと確立した接続をプールおよび共有でき、データベースの効率とアプリケーションのスケーラビリティが向上します。
会社の人曰く、これは料金が高いからあまり使いたくないらしい...
あかさたなS3について
あかさたなストレージクラス
- S3標準 : デフォルトのストレージクラス
- S3標準-IA : S3標準と比較して、格納コストが安価なストレージクラス。ただし読み出しにかかるコストは少し割高となっている。アクセスするときは高速なアクセスが必要だけど、頻度が少ないデータを格納するのに向いてる。
- S3標準 1ゾーン-IA : 1つのAZにしか保存されない。可用性が低いストレージクラス。他はS3標準-IAと同じ。
- S3 Intelligent-Tiering : アクセス頻度に応じて、適切なストレージクラスへ移動してくれる優れもの。コストパフォーマンスが良い。
- S3 Glacier Instant Retrival : アクセスに対する制限がない、唯一のS3 Glacierのストレージクラス。S3標準-IAと比較して、格納コストはより安く、読み出しはより高価になっている。
- S3 Glacier Flexible Retrival : オブジェクトに対する読み出しは数分から数時間かかる。
- S3 Glacier Deep Archive : オブジェクトに対する読み出しは最大12時間かかる。
あかさたなRedshift
あかさたなデータウェアハウス向けのデータベースサービス
（データウェアハウス…企業内の複数システムから大量のデータを時系列で蓄積するデータサーバー）
Redshiftの特徴
- 複数ノード（Redshiftクラスタ）による分散並列処理
- リーダーノード
- コンピュートノード
- ノードスライス
- 処理をする最小単位、コンピュートノード内でさらにリソースを分割したもの。ノード内のスライス数はコンピュートノードのインスタンスタイプによって異なる。
- 列指向型データベース
- 9種類の圧縮エンコード方式
- 列ごとに圧縮エンコード方式を決めることが可能
あかさたなRedshift Spectrum
S3に置かれたデータを外部テーブルとして定義できるようにし、Redshift内にデータを取り込むことなく、クエリの実行を可能にする拡張サービス