#はじめに
以下表は、
AWS の基礎 - 主要概念
の『パフォーマンス効率化』=>『設定』を表にしたものです。
何を使うか選択する時に結構役立つのではないかと思い表にしてみました。
以下記述はAWSのものからほとんど変更していません。
表の方が自分はわかりやすいなと感じ、、、作成しました。
使用されている用語等は下に一覧にしてみました。
#用語参考
| 用語 | 説明 |
|---|---|
| IOPS | 1秒あたりの入出力できる数の認識。AWSは課金でここの数増やせたりするよう |
| レイテンシー | 実際にデータが送られてくるまでの時間 |
| スループット | お仕事能力 |
| メモリ | 保持できる量 |
| CPU | 処理速度 |
#表
★AWS の同じタイプの各種サービスにおける主な違いは、その管理レベルとのことです。(カスタマイズどれくらい出来るかぐらいの認識で問題ないかと思ってます)
★同じものには同じ絵文字をつけました！
★最終的に使用するサービスの箇所には『
』を付けました！あとリンクにしました。
| カテゴリ | サービスのタイプ | 管理レベル | 設定方法の決定 | 詳細 |
|---|---|---|---|---|
 コンピューティング |
 VM ベース(より高額でより多くのメンテナンスの必要性可能性) |
EC2 (最大のコントロールを提供) |
インスタンスのサイズ (例: t3.small 対 t3.xlarge) およびインスタンスファミリー (例: r3.small 対 c5.small) がメモリと CPUに影響 | - |
|
コンピューティング |
VM ベース(より高額でより多くのメンテナンスの必要性可能性) |
Lightsail(EC2よりカスタム化の一部が使用できないがなんかいい体験ができるそう) |
インスタンスのサイズ (例: t3.small 対 t3.xlarge) およびインスタンスファミリー (例: r3.small 対 c5.small) がメモリと CPUに影響 | - |
|
コンピューティング |
VM ベース(より高額でより多くのメンテナンスの必要性可能性) |
Elastic Beanstalk (EC2とLightsailの中間的なもの) |
インスタンスのサイズ (例: t3.small 対 t3.xlarge) およびインスタンスファミリー (例: r3.small 対 c5.small) がメモリと CPUに影響 | - |
|
コンピューティング |
コンテナベース(設定が少し複雑です)ECS
|
- | メモリと CPU を個別に設定できます | - |
|
コンピューティング |
サーバーレスベース(管理がある程度簡単に出来ますが、ある程度制限があります)Lambda等 |
- | 直接設定できるのはメモリだけ、コンピューティング (およびその他システムリソース) の値は、利用可能なメモリ量に対して線形に増加します | - |
 ストレージ(静的ストレージ) |
ブロックストレージサービス(EBS) EC2 インスタンスからのデータを永続化するために最適 |
- | レイテンシー、スループット、および IOPS の要件を検討 | レイテンシーは選択したボリュームタイプによって変動、スループットは、ほとんどのボリュームタイプのボリュームサイズに比例、IOPS キャパシティーは、ほとんどのボリュームタイプのボリュームサイズに比例 |
|
ストレージ(静的ストレージ) |
ファイルシステム(EFS) 同じデータへのアクセスを複数のクライアントに提供するために最適 |
- | レイテンシー、スループット、および IOPS の要件を検討 | レイテンシーと IOPS は選択したパフォーマンスモードによって変動、スループットは、プロビジョニングされたスループットを使用する選択によって変動 |
|
ストレージ(静的ストレージ) |
オブジェクトストア(S3) 多数のクライアントによるアクセスが必要となる、複数の大きなデータの塊に最適 |
- | レイテンシー、スループット、の要件を検討 | レイテンシーは、バケットのエンドポイントまでの地理的な距離によって変動、スループットは、マルチパートアップロードなどのスループットが最適化された API の使用によって変動 |
|
ストレージ(静的ストレージ) |
アーカイブストレージ(S3 Glacier ) 頻繁にアクセスする必要がない大量のデータに最適 |
- | レイテンシー、スループット、の要件を検討 | レイテンシーは、バケットのエンドポイントまでの地理的な距離、および取得メソッドの選択によって変動、スループットは、マルチパートアップロードなどのスループットが最適化された API の使用によって変動 |
 データベース |
 リレーショナルデータベース(join等使えるがパフォーマンスとデータストレージに上限あり) |
RDS(ほとんどのもの使用可能) |
CPU、メモリ、ストレージを検討 | CPU、メモリ、ストレージは選択する EC2 インスタンスによって決まる |
|
データベース |
リレーショナルデータベース(join等使えるがパフォーマンスとデータストレージに上限あり) |
Aurora(特定バージョンの MySQL および PostgreSQL でしか機能しませんが、基盤となるストレージの管理を行い、クラスタリングサポートが組み込まれています) |
CPU、メモリ、ストレージを検討 | CPU、メモリ、ストレージは選択する EC2 インスタンスによって決まる |
|
データベース |
非リレーショナルデータベース(リレーショナルデータベースよりも大幅に高い上限までスケールできますがjoinなどない)DynamoDB
|
- | CPU、メモリ、ストレージを検討 | CPU、メモリ、ストレージはプロビジョニングされたキャパシティーなどの設定オプションによって決まる |
|
データベース |
データウェアハウスソリューション(構造化データへの迅速なアクセスによる大規模な分析を可能にする)Redshift
|
- | CPU、メモリ、ストレージを検討 | CPU、メモリ、ストレージは選択する EC2 インスタンスによって決まる |
|
データベース |
データのインデックス作成と検索ソリューション(さまざまなソースからのデータをインデックス化し、検索することができる)Elasticsearch Service
|
- | CPU、メモリ、ストレージを検討 | CPU、メモリ、ストレージは選択する EC2 インスタンスによって決まる |
#参考
aws
manageengine
kaonavi