Udemyのセールで購入した下記の講座が大変良かったので、紹介するとともに学び直した内容の備忘録を残しておくことにした。なのでこの記事で特定のAWSの機能の設定の仕方などは書いてはいない。Linuxの基本的なことはわかっている人がAWSを体系的にどうやって学んだのか、どういう理解の仕方をしたのかを知ることができるという内容だ。
作者の方の紹介ページ www.ketancho.net
こちらの副読本とした。 比較的新しい本であり上記の作者の方も作者に名を連ねているところから、用語の説明の仕方などにUdemyの講座とブレが少なく理解しやすそうなのでこちらを選んだ
Amazon Web Services パターン別構築・運用ガイド 改訂第2版 (Informatics&IDEA)
- 作者: NRIネットコム株式会社,佐々木拓郎,林晋一郎,小西秀和,佐藤瞬
- 出版社/メーカー: SBクリエイティブ
- 発売日: 2018/03/23
- メディア: 単行本
- この商品を含むブログ (1件) を見る
Amazon Web Services 業務システム設計・移行ガイド (Informatics&IDEA)
- 作者: 佐々木拓郎,林晋一郎,瀬戸島敏宏,宮川亮,金澤圭
- 出版社/メーカー: SBクリエイティブ
- 発売日: 2018/01/20
- メディア: 単行本
- この商品を含むブログ (1件) を見る
ついでに上記のブログでおすすめされていたサーバレスの本も買った
Amazon Web Servicesを使ったサーバーレスアプリケーション開発ガイド
- 作者: 西谷圭介
- 出版社/メーカー: マイナビ出版
- 発売日: 2018/03/16
- メディア: 単行本（ソフトカバー）
- この商品を含むブログを見る
はじめに
何年も前からAWSを使うことはあっても体系的に学んでいなかったし、必要なところだけ設定していた。特にIAMやVPC、ELBあたりは雰囲気で使っているところがあった。 AWSのメジャーなサービスをザクッと把握して何ができて何ができないのかインデックスを作っておきたかったというわけだ。
AWS学び直し備忘録
初期設定
アカウント作成
- Rootユーザは基本使わない
- サービスごとにアドミンユーザを作るのが良い
- 各アドミンユーザから、適宜利用者ごとにIAMユーザを作る
- 最初はAdminAccessのユーザを作る。このアカウントでRDSやEC2も作る
IAMユーザ
- 利用者ごとに作る
- 最初はAdminAccessのユーザを作った。このアカウントでRDSやEC2も作る
- IAMユーザはIAMユーザ用のサインインリンクからログインする
- IAMのマネジメントコンソールのダッシュボードにURLが書いてある
- IAMロールとIAMユーザIAMポリシーは別のもの
CoudTrail
Cloudwatchの設定
- 請求アラートの設定をしておく
AWS見積もり方
- AWS サービス名 pricingで検索する
- Simple monthly calculator 月々の使う場合の見積もり
EC2
セキュリティグループ
- ファイアーウォールのこと
- 開けるポートを選ぶ、HTTPとかSSH向け
- あるセキュリティグループがついているEC2からのみ通信を許可するというような設定ができる
キーペア
- SSHのキーペアのこと
- SSH接続するのに使う
AMIとスナップショットの違い
- AMI => ディスクイメージ OSとかまるごと
- スナップショット => EBSつまりハードディスクのバックアップ
EIP
- ec2の固定IP
- 注意、動いていないインスタンスに紐付いてないと微妙に課金される。紐付いていれば課金されない
AWSネットワーク
リージョン
- 地域 アヴェイラリティゾーン(AZ)
- データセンターのこと
- ap-northeast-1a、1c, 1dは別のデータセンターと考えて良い
- なのでリージョンのAZだと、東京リージョンにあるデータセンターである。東京リージョンは現在3つのAZがある
VPC
- 独自のネットワークだけど、AZをまたがって作ることができる。マルチAZにする。負荷分散やディザスタリカバリ対応
- サブネット、外部にアクセス可能なものや、アクセスさせないものに分けることができる
- サブネットはAZをまたげない
- WEBサーバはマルチAZで作って可用性を上げるのが基本
- CIDR
- サブネットマスクの別表記
- プライベートサブネット内にあるEC2に接続するのにNAT GWを使う。
- NAT GWはパブリックサブネット内に置く、昔はWebサーバを踏み台にして接続していたような気がする
- ACLとIAMと(セキュリティグループも若干）はやや混同している、機能がかぶっているところがある気がする。
- パブリックサブネットとプライベートサブネット
- パブリックはDMZ的なEC2のWebサーバ置く
- プライベートはRDSやバッチサーバを置く
- ルートテーブル
- パブリックサブネットはインターネットに出ていくのと、入ってくる設定
- プライベートサブネットの場合は、VPC内の通信だけなら許すようにする
- UserData
- EC2立てるときに高度な設定にあるテキストエリア。シェルスクリプトを実行する
- EC2のオートスケールはAMIを読み出すのでここでAnsible的なことを頑張らなくても良さそう。実務ではあまり使わなそう
- VPC内のサーバのIPアドレスはプライベートIP
NAT GW
ネットワークACL
- セキュリティグループと似ている
- サブネットのごとにポートアクセス制限を書けることができる
- セキュリティグループとの違いは
- サブネットごとにまとめて、開放ポートの制限などを書けることができる
- in/outの通信の両方の設定する必要がある
RDS
- RDMSのことMySQLやPostgreSQLなどなど
- パブリックアクセシビリティを有効にするとグローバルIPアドレスが振られる
- 多分サブネット側でネットワークの口が閉じているとアクセスできない。通常RDSはプライベートサブネットに置くので、パブリックアクセシビリティをOnにすることはなさそう
- フェイルオーバーがうまくいったかどうかをどうやって確認するかまだよくわかってない
- マルチAZの設定は明示的にAZを選択できない？2つのAZのどちらがマスターにするか指定できない？Webサーバと同じAZに置きたいよね？
ELB
- ロードバランサ
- オートスケールもここで設定する
- SPOF => 単一障害点 のこと。これを作らない構成にするのが良い
- ALB => アプリケーションロードバランサ、ELBの種類の一つ。基本的にこれを使えばOK
- URLごとに振り分けたりする。Nginxのリバースプロキシでやらせるようなことをやる
- アクセスの負荷分散もALBでできる
- サーバのヘルスチェックを行える
- ヘルスチェックでコケたらメール通知(Slackも)できる ELB + CloudWatchアラームを使ったEC2サービス監視プラクティス ｜ DevelopersIO
- AutoSclingは2−6に増やせる。また時間を設定して自動的に増やすことができる(テレビ対応とかの場合)
- ELBはサブネットの外側、VPCの入り口のイメージ
- ALBの設定画面はAWSのWebコンソールのEC2のメニュー内のロードバランサところにある
- ALBのターゲットグループの設定でぶら下がっているサーバのヘルスチェックのステータスがわかる
- ALBのヘルスチェックは、繋がらなくなると切り離され、切り離されている間もヘルスチェックはされて、healtyになったら接続されるようになる
- オートスケール機能は、ターゲットグループの設定によってできるようになる
- AMIが対象になる。プログラムのコードを最新にするようなときはどうするのだろうか。CodeDeployの設定でAMIを作ってどうにか対応できそう AWS CodeDeploy を Amazon EC2 Auto Scaling と統合する - AWS CodeDeploy
- オートスケールの機能もEC2のメニュー内にある
- オートスケール設定はターゲットグループに紐付いている
- ターゲットグループは、ALBに紐付いている
- オートスケールでスケールインとスケールアウトの両方できる
S3
- よく使うファイル置き場、ログも置ける
- 静的ホスティングもできる
- エラー画面を作る
- ALBの設定でヘルスチェックが全滅の場合にこちらを向ける設定ができるっぽい
- 表示するエラーは404とか500番はアプリ側で出す気がするけど、504番エラーとかかな？
Route53
- おなじみDNSサーバ、他にも接続先をS3やELB、CloudFrontにエイリアスでできる
− DNSフェイルオーバー機能で、ELBのサーバが動かないときにソーリーページを表示する
- Failoverは落ちたときに切り替えができる
- 他にもELB(かな？)の振り分けができてA/Bテストができる、カナリアリリース(一部の人にだけなにかする)ができる
IAM
- 権限周りの機能。これが結構ややこしい
- IAMユーザは個別のユーザ、メールアドレスに紐づく
- IAMグループはユーザをまとめて紐付けると権限が付与されて便利
- RDSの参照、編集権限とか、ECSの削除権限など
- 担当者ごとにIAMユーザを発行して作る。
- 運用をイメージすると、IAMグループのアプリ開発者向けのIAMユーザ= アカウントを渡す。
- IAMロール
- IAMポリシー
- IAMグループやIAMユーザに紐付ける権限のセット
- EC2インスタンスの設定画面のアクションからIAMロールの割当/置換から設定できる
- ベストプラクティス
- AWSにアクセスする人はひとりひとりIAMユーザを作る。IAMグループでいくつかのグループを作る。
- 権限は必要最小限にする
AWS CLI
- awsのウェブコンソールをターミナルからコマンドラインで操作できるようにするもの
- ~/.awsディレクトリのconfigureにawsのアクセスキーやシークレットキー情報が格納されている
- 複数のIAMユーザでcliを操作したい場合は
aws configure --profile NAMEでNAMEの名前のユーザを切り替えながら作業ができる。 - 基本的にリファレンスを見ながらやる
- バッチ処理なんかで使いそう
- やったことのある事例は、本番環境のS3にあるバケットを差分コピーして、ステージング環境にデイリーで移行するバッチ
Cloudwatch
- メトリクス(リソース状況を計測するツール)
- 金額がかかりすぎた場合のアラートや、CPU使用率の通知はSNSを通じてメール送信したりする。slackに通知も投げれる。
- makarelなどを併用しているところが多いイメージがあるがそれはなんでなんだろ？
- Cloudwatchlogはpaper trailのAWSの版
CloudFront
- CDN
- コンテンツのパージが遅いというが2018年末だと現状はどうだろう？
- Route53の設定して名前解決してみたい
- Cloudfrontを正面においた場合ユーザ独自情報、動的コンテンツはどうなるのかな
- ビヘイビアの設定で、コンテンツごとにキャッシュする時間を決められる。URLごとに設定可能、precedenceで優先度設定できる
- HTTP2にブラウザが対応していたら、そのプロトコルで返したり、gzで圧縮するのもここでできるらしい
- TTL 0に下だけだとうっすらキャッシュされるので、きちんとキャッシュしない設定をする必要がある
- キャッシュの削除は昔は結構かかってるイメージが合ったが最近は５分ぐらいらしいまじで？ Fastlyは一瞬だけども
ElastiCache
- ElasticCacheじゃなくてElastiCacheなのね。
- memcacheかredisか選べる。memachedはマルチスレッドで、redisはシングルスレッド。多分価格を抑えたかったらセッション管理ならmemcachedの方が良いかも
- セッション管理とキャッシュ処理、キューイングなどをまとめてRedisでやることが多いかな
SES
- メールサービス
- バウンス処理や到達ステータスの管理は未だにないみたいだ。この機能作るのだるかったから、SendGridに頼ったほうが生産性が高そうだ。Sendgridの方が携帯電話会社のドメインに届きやすいとか聴いたことあるけど現状どうだろうか
SQS
- マネージドのキューイングサービス、RailsでつくつるならRedisでSidekiqを使ったほうが再試行や管理画面の構築上楽かもしれない。 -SQS向けにsyoryukenというgemがある
- SQSを使うならLambdaを噛ませたほうがクラウドネイティブっぽくて良さそう。キューならLambdaとRDSの組み合わせでも筋が悪くない
CodeCommit
- Gitのホスティングサービス。PRにも対応しているようだが、Githubに人気が集中していて人気がない
- Issue管理をGithubでしないでTrelloやJira、Backlogなどでやるなら選択肢としてありかも
CodeBuild
- CIサービス、CodeCommitだけではなく、githubやbitbucketにも対応している。ただし人気がないCircleCIに人気が集中している。なぜだ
CodeDeploy
- CDサービス、オーケストレーションもする？
- Blue-Greenデプロイも簡単にできそうな設定がある
CloudFormation
- インフラの自動構築サービス。AWSを構築するサービスをしている会社は概ねこちらを用いいるようだ
- ymlやjsonでVPCやEC2などもろもろ設定できる。ymlの方がコメントが書けるので良さそう
- 同様の機能にHashiCorp社の製のterraformがある
- 両者を比較する記事もあるが、CloudFormationの弱いところは2018年現在ではなさそう
- terraformもCloudFormationのファイルに変換する機能があればイイんじゃないのかなー知らんけど
- CloudFormationで設定した構成を手動で変更した場合に検知できる機能(ドリフト監視)があるので便利。最近の機能
- Kubernetesを展開するサービスEKSもCloudFormationで設定できるようだ。
- EKSはサブネット内の設定をするのかな？この辺はよくわかってないAZ間をまたげそうだけれども
- ざっくりCloudfrontの方が低レイヤーと考えておけば良さそう
- キーペアの生成はCloudFormationではできないっぽい。aws cliかブラウザのコンソールで生成する
感想
- VPC, IAM, ELBなど普通のLinuxにはない設定を理解できた。もともとLPIC のレベル２までは持ってたのでその差分が理解できた
- CloudFormationを簡単に作れる仕組みがあればいいのにね。構成のノウハウやコードを共有するサイトやサービスがあればいいのにAWSが公式にやればいいのになー
- EC2や普通のRDSを使った構成で作るのはセキュリティパッチなど考えないといけないから、そういう構成なら中規模なアプリならHerokuなどのPaaSのほうが楽かな
- インフラに関してはAWSのすげぇインフラエンジニアに任せられるサーバレスでアーキテクチャ構成を作っていきたい
Udemyレッスンのリンク
副読本
Amazon Web Services パターン別構築・運用ガイド 改訂第2版 (Informatics&IDEA)
