あらすじ
※この商品はタブレットなど大きいディスプレイを備えた端末で読むことに適しています。また、文字だけを拡大することや、文字列のハイライト、検索、辞書の参照、引用などの機能が使用できません。
近年、Webサービスの新規開発ではクラウド利用を前提とすることが当たり前になりつつあります。とはいえ、実際に開発するとなると、公式サイトの膨大なドキュメントと機能を前に途方にくれてしまうのではないでしょうか。本書は、クラウドを業務に使おうとして初期構築に悩んでいる人や、運用しているシステムを改善したい人のためのガイドブックです。AWS、GCPのインフラサーバ構築に役立つ豊富なテクニックを多数紹介します。
感情タグBEST3
Posted by ブクログ
これまでインフラ設計をぶっつけ本番で現場でやってきたが、セオリーを把握しておきたい、と手に取った。
自分はずっとオンプレで、本書を読んだ当時もオンプレ案件に携わっていたためオンプレ設計を期待していたが、完全に間違えた。本書はクラウド用である。
で、クラウドならではの特徴や、オンプレとの違いなどを把握できれば、と思い読み進めてみた。
が、やはりクラウドはそのサービス専門の用語や概念が多く、なかなか実感として掴むことができなかった。IAMの仕組みなどは興味深い。
AWSクラウドの資格取得用のテキストを見ながら実物を触ってみるといった経験がないと、やはり設計部分に踏み込むのは難しい気がする。
自分の肥やしにならなかったのは自分自身に非があるが、それでももう少し分かりやすく解説できるんじゃないかな、と思ってしまった。
Posted by ブクログ
■運用しやすいシステム
・手作業が多い
・監視がややこしい
・オンプレミス環境と同じような管理をしようとした
・１サーバで複数の機能を持たせる
・初期開発のシステムをそのまま拡張する
■アカウント設計方針
・プロダクト用アカウント
先述の通り、まずサービスごとに1アカウントが必要です。各サービスの開発環境と本番環境でアカウントを分けることもありますが、分けないこともあります。規模が小さいシステムなら開発環境と本番環境を1アカウントに集約した方がアカウント切替の手間が省けますが、IaC(Infrastructure as Code) ツールの利用が難しくなるという問題があります。
IaCは開発環境でテストしてから本番環境に適用すべきなので、開発環 境と本番環境を分割しましょう。当初は使わなくても将来的なIC導入を考慮すると、アカウントは分けておく方がよいでしょう。
・サンドボックスアカウント
・ログ保存用アカウント
AWSでもGCPでも各アカウントを束ねて「組織」を作れます。組織を活用すると、請求を一括化したり一括でセキュリティポリシーを定めたりできます。複数アカウントを作ってから組織化するのは困難が伴うため、１アカウントしかないときから組織を設定するのがおすすめです。
組織のメリットは以下のようなものがあります。
・請求の一括化＆スケールメリットの享受
・セキュリティルールの自動設定
■IAMの設計
・権限は最小限に
・人間が使うユーザーとプログラムが使うユーザーは分ける
・プログラムから使うユーザーはなるべくクラウド管理の鍵で認証する
・ユーザーは複数人・複数プログラムで使い回さない
■bastionサーバを構築する利点
・監査がしやすい
・最小限のサービス
■マネージドサービスのメリット
・運用難易度が高いサービスを運用しなくてもよくなる
・専用サービスが使える
■マネージドサービスのデメリット
・特殊なワークロードに対応しない
・コストが高い
・ベンダーロックイン
・ブラックボックス化
