EC2やLambdaはちょいちょい使ってはいたんだけど、ちゃんとAWSを勉強したくなったのでこの本を読みました。
AWSのそれぞれの機能はもちろんですが、インフラ設計における観点を学べたので紹介します。
本の選定
まず、AWS本は本当に色々あったのでどの本を購入するか、以下の観点で絞りました。
- AWSの基本が抑えられること
- 未経験者向け、サーバ・インフラの基礎説明は省かれていること
- 骨太で情報量がしっかりあること
その結果、Amazon Web Services パターン別構築・運用ガイドと、どちらにするかまで絞られました。
AWS知識のない状態では甲乙つけられなかったので、日々新しくなるAWSという側面から
発売日の新しいAmazon Web Servicesインフラサービス活用大全にしました。
ただ、買ってから気付いたのですが本書は海外の翻訳版で、元の本の発売は同時期でした。
読んでみて
詳細な内容は本書に譲りますが、ざっとあげると
- 一貫してCloudFormationで構築してくれている
- EC2, VPC, Lambda, S3, EFS, RDS, ELB, SQSなど基本的な項目を網羅
- ECS, CodePipelineなどには触れない
- 買ってよかった
しっかりと情報量のある本だったので、読み手のスキルによって読んで得られるものは違うんだろうなと感じました。
自分はそれなりにAWSのキーワード・機能・使いどころはなんとなくわかっているつもりでした。そう思っていた上で、自分が感じたことを記します。
可用性と耐用性
自分は今までユーザに使ってもらうためのWebサービス・アプリをコーディングし、ソースコードの実装の仕方やバグでサービスや機能停止しないことに注力してきました。
Webサーバが落ちないという広い意味では同じなのですが、AWSはWebサービスやアプリを支えるインフラとして落ちないために
- ハードウェア・OSクラッシュ
- データセンター停止
という２点をカバーできる・カバーするためのインフラとしてAWSはある。
AWSを使うということは、可能性と耐用性を保障するのかしないのか
利用者が選びながら設計するものなんだと知ることができました。
負荷分散とスケーラビリティ
前述の落ちる要因とは別に、アクセス集中や重い処理によりサーバが十分に処理できずWebサービスが停止・半停止となってしまうケースがあります。
そのためにAWSでは、
- 読み取りに比べて、登録・更新処理は時間がかかる
- 登録・更新はSQSに一旦ためて、非同期で別サーバで行う
- 別サーバは表側のWebサーバとは別にできる
- 別サーバが重くてもWebサーバは落ちないので、サービスとしては全部落ちることはない
- また、別サーバだけオートスケールさせ十分な台数のサーバで捌ける
- サーバ台数可変なので、利用した分だけコストも最適化できる
というユースケースでSQS利用できる。
地味だと思っていたSQSの認識を改めることができました。
メッセージキュー（SQS）で非同期にするには、依頼した処理が今どの処理状態にあるのか、データの記録と状態管理が必要になります。
サービスインしてからボトルネックを、再設計することは大変難しいので
Webサービスをデザインする時、ボトルネックとなりそうな箇所に予め入れこむか・入れ込めるようにデザインすることが大事だと思いました。
本書から、この２つ知ることができたので１番の収穫でした。
- Webサーバが落ちるという一言には、色々なレイヤー・理由があること
- メッセージキューで新規・更新処理を分散・状態管理できる設計観点
ただ、2020年12月時点とは細かいところ・機能のトレンドに違いがあるので
利用前には現時点でのトレンドを調べてから利用したいと思いました。