AWSome Day 2019 東京 (自分用メモ)
AWSome Day 東京 2019の受講メモです。PDFは参加者のみダウンロード可なので載せていませんが、汎用的な内容なので特別な情報はなかった印象です。
https://pages.awscloud.com/AWSomeDayTokyo20190722.html?trk=event_awsome_page
講義メモ
AWSのグローバルインフラストラクチャとネットワークおよびコンピューティング
AWS の基礎であるグローバルインフラストラクチャと、その上でご利用いただく仮想ネットワークサービスの Amazon Virtual Private Cloud (VPC)、仮想サーバーの Amazon Elastic Compute Cloud(EC2)、クラウドならではの動的にサーバー台数を調整できる AutoScaling についてお話しします。 このセッションを通して、AWS のサービスの基本を学習することができます。
VPC
- VPCの中の単位を切り分けたもの: サブネット
- パブリックサブネット
- プライベートサブネット
LightSail
プライベートサーバー、VPレスといわれる部類らしい
EC2
EC2インスタンスの起動デモ
- インスタンスの立ち上げ方は複数、最初から設定するか、AMIから選択するか
- 今回はAmazon Linux 2
- インスタンスタイプを選択(スペック)
- GPU特化のタイプもある(
p
ファミリーなど)
- GPU特化のタイプもある(
- インスタンス作成時のスクリプトを書ける(
yum install
など) - SSH接続では公開鍵を使う
- インスタンスタイプのネーミングには決まりがある
- ファミリー、世代、インスタンスサイズ
CloudWatchによってEC2を監視する。ハイパーバイザレベルで値を監視し、アプリケーションの監視情報をCloudWatchへ送ることができる、アラームはEメールやSMSなどで送ることができる
CloudWatchにはCronの実行や、Lambdaの実行も設定することができる
Elastic Load Balancing
ロードバランサ。負荷分散、EC2のヘルスチェックなど。外部向けにも内部向けにも置くことができる
ELBはマネージドサービスなので、複数用意したり負荷を考慮したり、ということはAWSがやってくれるのでユーザーは考慮しなくてよい
ALBはリクエストレベル(レイヤー7)、NLBは接続レベル(レイヤー4)で動作する
EC2 Auto Scaling
動的なサーバーの追加・削除を設定する
スケールアウト・スケールインの条件を設定する、CloudWatchの監視機能を使い、アラームをAuto Scalingに送るころで自動化ができる
Auto ScalingはWebサーバーと組み合わせて言及されることが多いが、他にも利用することが可能
ファイルサーバーの監視を行う監視サーバーは、落ちたときに自動的に復帰するようにしたい、このとき、Auto Scalingに最大1、最小1台として設定すると、落ちた(0台になった)場合に1台を再生成することができる
Auto Scalingはサーバーの数を増減させる以外に、一定に保つ役目も持つ
CPU使用率がXX%になるようにスケールイン・アウトさせることも可能
ストレージとデータベース
アマゾン ウェブ サービス ジャパン株式会社 AWS トレーニングサービス本部 テクニカルトレーナー
このセッションでは、ストレージサービスであるAmazon Simple Storage Service(S3)とAmazon Elastic Block Store(EBS)について、また、Amazon Relational Database Service(RDS)、Amazon DynamoDBをはじめとする各種データベース機能について体系的にご理解いただきます。
ストレージ
- ローカルストレージ
- EBS
- 複数のサーバーからアクセスできるストレージ
- RDBMS(RDS)
- NoSQL(DynamoDB)
- 共有ストレージ(S3)
ローカルストレージ(EBS)
- AZ内で自動的にレプリケート
- スナップショットをS3内に保存
ボリュームタイプはハードディスクタイプとSSDタイプに分かれる。HDDはスループットが高いのが特徴(大きいデータを持ちシーケンシャルに読み書きする)
SSDタイプはIOPS(1秒あたりの読み書き回数)が高い。
プロビジョンドIOPSタイプは、IOPSをユーザーが指定することが可能。
暗号化機能が自動的に提供される。
伸縮性として、キャパシティーの変更やタイプの変更に対応している。
EBSのライフサイクル
EBSはEBSサーバーがリージョン内に存在し、その中からユーザーが必要とするストレージを切り出すことで作成される(CreateVolume
)。EBSのデフォルトサイズは8GB。
作成したボリュームはEC2インスタンスにアタッチされることで使用が可能になる。
デタッチすることでEBSは削除される(DeleteVolume
)。
共有ストレージ(S3)
Amazon Simple Storage Service。
インターネット対応のストレージ。どこからでもアクセス可能。
アカウントあたり最大100のバケットを所有できる、バケットとそのオブジェクトのアクセスログを制御できる、オブジェクトに対してメタデータを記録できる。
S3バケット
バケットの名称が、トップレベルのネームスペースとなる(C:\
のようなもの)。オブジェクトに対しては、バケット内における一意の名称をオブジェクトキーとして付与する。バケットの名称は世界中で一意にする。
- アプリケーションアセットの保存
- 静的ウェブホスティング
- バックアップと災害対策
- ビックデータ用のステージング領域
- ビックデータ用のデータは大容量になるためS3が向いている
RDBMS(RDS)
リレーショナル・データベースを扱うサービス。
オープンソース、商用のDBをエンジンとして使用できる。またAmazon Auroraも使用することができる。各データベースのすべての機能を利用できる。時間のかかるDBの管理タスクが不要になる。
RDSはマネージド型サービスなので、オンプレでDBを運用する場合に比べて多くのタスクをAWS任せにすることができる。
各DBについて、ユーザーの用途やアプリケーション事由に合わせて細かくバージョンを指定できる。
バックアップ
自動バックアップ、手動スナップショットを利用することができる。
自動バックアップはトランザクションごとに保持するので、特定の時点にピンポイントで戻ることができる。
アーキテクチャー
一般的にはRDSはプライベートサブネットに配置し、パブリックなEC2などからアクセスされるように設定することになる。
スタンバイインスタンスを用意する場合は、マスターとは他のAZにスタンバイインスタンスを配置する。マスターとスタンバイは同期されるように設定する。マスターに障害が発生した場合は、フェイルオーバーとしてEC2からスタンバイを見るように切り替えることができる。フェイルオーバーは通常60〜120秒の間に実行される。
リードレプリカ
非同期レプリケーション。リードレプリカは読み込みのみできるように設定され、大量の読み込み処理が必要な場合に有効。
NoSQL Database(DynamoDB)
DynamoDBはKVS型のデータベース。水平スケーリング(サーバーの台数を増減させる)を採用した内部設計。ちなみにRDBは一般的に垂直スケーリング。
- 保存できるデータ量に制限がない。
- SSDを使用して、高速で予測可能なパフォーマンスを実現する。
- 各テーブルに必要な読み書き性能(リクエストキャパシティー)を指定することができる。(1秒間に何回読み書きするのか)。例えば秒間1000回という指定もOK。
ユースケース
- 順位表、スコア表
- セッションデータ、一時データ
- メタデータテーブルやルックアップテーブル
データモデル
項目は属性の集まり。項目の中に属性(name, age, mail_adress, )を持つ。属性の個数や種類は項目ごとに異なっていても構わない。アプリケーションが更新されるとデータモデルも更新されるが、その際の対応が早くなるのがDynamoDB。
読み込みには、「結果的整合性」と「強い整合性」がある。この違いは?→ここを読んでなんとなくわかった https://qiita.com/uenohara/items/44d2334c597dc631bc60
DBの選択
それぞれのメリデメを踏まえて選択する。例えば、IoTのような読み込み・書き込み頻度が高い場合はDynamoDBの方が向いているケースが多い。
セキュリティの基本
IAMがなんとなくしか分かっていないので抑えたいな−
責任共有モデル
ユーザーとAWSの責任境界を示す。例えば、OSにパッチを当てるか否かについてはユーザーの責任となる。一口に責任共有モデルといっても、使うサービスによって具体的なユーザーのタスクは変わってくる。料金とは別に運用コストなども考慮してサービスやアーキテクチャを選択する。
ネットワーク
VPC
- ファイアウォール
- ネットワークの経路制御
- ルートテーブル(ルーティング情報を管理)
- インターネットとの通信
- オンプレミス環境との接続
ファイアウォール
インターネットゲートウェイの設置によってVPCにアクセスできる。ルートテーブルによってどのサブネットにアクセスするか決まる。サブネットとの通信時にネットワークACLがあり、通す・通さないを決定する。
サブネット内のインスタンスに対しては、セキュリティグループを挟むことによって通信を制御する。
1つのセキュリティグループを複数のEC2インスタンスに適用することができる。このようにまとめることで、セキュリティグループを編集することで一括して反映することができる。
インターネットからの通信はWebサーバーにのみ許可することで、APサーバーやDBなどはプライベートサブネットに置くことができる。また、管理者からのアクセスはSSHのみ、RDPのみという形で制限することができる。
AWSの認証とアクセス管理
IAM
Identity and Access Management。ユーザーとグループの作成、権限(ポリシー)とロールの付与(ポリシーのアタッチ)を行う。
AWSでは、マネジメントコンソール以外に、AWS CLIまたはAWS SDKによるアクセスが可能である。
アクセスキーとシークレットキーによるアクセスは極力使用しないことを推奨する。(盗まれる可能性があるため)
メールアドレスでのログイン=ルートユーザーでのログインになる。ルートユーザーではAWSの操作を行わず、権限を制限したIAMユーザーのみを作成し、そのIAMユーザーで作業する。
IAMポリシーの招待はJSON形式のファイルである。権限を組み合わせてIAMロールを作成し、これをユーザーやAWSサービスにアタッチする。
IAMポリシーを直接ユーザーにアタッチする→一旦与えると管理者が変更しない限り永続的なものになる
IAMポリシーを付与したロールをアタッチする→有効期限があるので、一時的な権限付与を設定することができる。(一旦与えた権限が残りっぱなし、ということはよくあるなあ…)
また、EC2のようなAWSサービスに対して、IAMロールを付与することが可能。こうすることで、例えばEC2上のPython3からS3にアクセスする場合、ソースコード上にアクセスキーを記述することなく権限を付与することができる(ロールをアタッチしない場合直接アクセスキーを記述する必要があり、GitHubなどに公開されないか注意する必要がなくなる)。
例えばPython3でS3にアクセスする際、boto3
に権限情報を設定するコードを書くことなくS3から情報を取得できる(どうやってんだろ、環境変数ですかね)
IAM周りのベストプラクティス
- ルートアカウントは使わない
- IAMユーザーに最小権限を付与する(モグラ叩きになるけどね)
- どの権限を使えばいいか分からない場合は、アクセスアドバイザーを使うといいかもしれないです
- グループで一括管理する
- 強力なパスワードポリシーを付与する
- MFAを有効にする(少なくともルートアカウントや管理ユーザー)
セキュリティリソース
Trusted Adviser
基本機能は無料。サポートレベルによって見られるアドバイスの範囲は変化する。本番環境以上ではBusiness以上を推奨
Well-Architected Framework と料金の話
Well-Architected Framework
クラウド最適化のためのフレームワーク。2015年に発表され、毎年アップデートされ続けている。10年以上の経験から成り立っている。
質問形式で書かれており、その質問に回答することで最適化を検討することができる。AWS公式サイトからダウンロード可能。
設計原則
6つの原則から成り立つ。
例えば、「必要なキャパシティを勘に頼らない」。オンプレの場合はキャパシティを予測していたが、これらはたいてい多少なりとも予想が外れていた。クラウドの場合は、オートスケーリングによってキャパシティを増減させることができるので、予測せず実績に合わせて都度判断することができる。
5つの柱
設計原則も含めた5つの観点があり、各項目はこれに基づく。
運用情報優秀性の柱
準備、運用、進化
例えば「運用のコード化」について。AWSマネジメントコンソールへの操作によってAWS作業を行うことができるが、この作業をコード化することを検討し着手する。すべてのAWS作業は設定ファイルに記述することができ、具体的にはCloud Formationを利用して管理することができる。コード化することによって、テスト環境、ステージング・本番環境などといった同じような環境構築作成中にミスや長時間作業が回避できる。
セキュリティの柱
トレーサビリティの確保にはCloudTrailを利用して、ユーザーの全操作履歴を記録、監視する。
信頼性の柱
Auto Scalingではインスタンスの数を増減させるだけでなく、障害によってインスタンスが使えなくなっても再作成することによって常に同じ数になるよう設定することも可能。
パフォーマンス効率の柱
例えば、最新技術を積極的に導入することが提唱されている。AWSの新しいサービスについても、既存のシステムに導入することができないか検討するべき。
また、サーバーレスアーキテクチャを使用することを検討する。例えばAWS Lambdaがサーバーレスサービスの代表となる。使い方によってはLambdaがEC2よりも高いパフォーマンスを発揮することができる。また、Lambdaは起動時のみ料金が発生するので、EC2よりも料金発生時間が短くなる。
コスト最適化の柱
例えば「従量課金モデルを採用する」。大きな初期投資をせず、使用しただけ払う仕組みを活用する。
「関連支出を分析する」。オンプレではサーバーを管理するための施設費や家賃、人件費といったものもコストに含まれていたが、AWSではこれらがマネージドになる。
料金の基礎
料金モデル
例えば、EC2のt2microは1ヶ月丸々起動で1200円ほどかかるが、夜間や休日など稼働時間を調整したりすることによってコストを削減できる。
AWS無料利用枠
無期限で利用できる無料利用枠も存在する。例えば以下:
- DyamoDB: 毎月25GBまで無料
また他のサービスと組み合わせるものについては追加料金なしで使用できるものもある。
利用内訳
一般的にはEC2とRDSが利用料金の大半を占める。これらをどれだけ節約できるかに注力するのが効率的。
料金計算例
EC2
- 料金ファクター
- 購入タイプ
また、ロードバランサにも料金が発生する(オンプレミスではなかなかの価格になるんだって):
- 実行時間数
- 処理するデータ量
モニタリング(CloudWatch)の料金:
- 基本モニタリングは無料(5分単位の測定、デフォルトではこれを使用)
- 詳細モニタリング(使用できるメトリクスが増加、1分ごとの測定、一定の月額料金となる)
Auto Scaling自体は無料。
Elastic IPアドレスについては、実行中のインスタンスに関連付けられた1つのElastic IPアドレスを無料で利用できる(IPを専有したままどこにもアタッチしない場合には課金対象となる)。
S3
ストレージクラスの種類によって異なる。標準ストレージよりも標準低頻度アクセス(IA)を選択すると若干安くなるが、可用性の減少および取り出しに別途料金が発生するため、利用目的に合わせて選択する。
IAストレージには、例えばバックアップ用のバケット(書き込みは多いが取り出しは少ない)に対して採用する。
リクエストの数によっても変動する。PUT/GETに対して1000回あたりの料金が設定されている。PUT/GETの回数をへらす設計や実装がコスト削減につながる(多数のファイルをZIPなどにまとめてPUT/GETする、など)。
EBS
IOPSの設定によって料金体系は変化する。また、スナップショットの保存についても、保存されるデータのギガバイト月あたり料金が追加される。
複数回のスナップショットの差分のみを取得する、という仕組みを取ることで、合計の課金額が節約される。
RDS
時間単位、確保したストレージによって課金が発生する。現在は秒単位で計算される(最低で10分間)。使用しない場合に停止することで節約できる。
また、DBのインスタンスタイプによって変動する。RDSもリザーブドインスタンスによって節約できる。
簡易見積りツール
簡易見積りツールというサイトを利用することができる。AWS calc
でだいたい見つかります。フォームに従って入力することによって料金試算を見ることができる。
また、TCO計算ツールを利用すると、オンプレミスでの料金を試算することで、クラウドとオンプレミスを比較することができる。