プログラマでありたい

おっさんになっても、プログラマでありつづけたい

Amazon Web Services 業務システム設計・移行ガイドの増刷決定しました

2018年1月20日発売のAmazon Web Services 業務システム設計・移行ガイド ですが、発売3週間で増刷決定しました。ありがとうございます!!

本書のターゲット


 本書のターゲットは、企業内でAWSを構築・運用する立場の人、或いはその導入を支援するSIerで働く人を対象に書かれています。レベル的には、初心者ならびに初心者を脱して中級者を目指す人を想定しています。まぁ下のポップの金澤さんの意気込みどおりです。私は、とにかく楽したいしか頭にありません。

f:id:dkfj:20180129194052j:plain

売れ行きの推移


 ネット上でのレビューなどが、まだあまり出ていないので地味です。しかし、なかなか堅調な売れ行きで、Amazonでの売り行き推移も手堅いです。
f:id:dkfj:20180208072620p:plain

 書店巡りしていても、結構手に取ってパラパラめくってくれている人を目にするので、関心が多い分野なのかもしれません。手に取った人は、そのまま買ってくれても良くてですよ。

増刷にあたり


 今回の増刷にあたっては、大きな修正はしません。誤字脱字を修正するくらいです。後は巻末のプロフィールにそれぞれどこの執筆担当だったのかを書こうかなと考えています。Kindle版で購入している方は、最新化できるので是非してみてください。

感想


 著者にとって、増刷ほど嬉しい言葉はありません。何故なら、何もしなくても印税が入るからです。自分達が書いたものが、世の人に必要とされていたということの証左だからです。仕事しながら執筆するのは、なかなか大変なところもありますが、もう少し頑張ります。とりあえず今は、Amazon Web Services パターン別構築・運用ガイド 改訂第2版を書いています。

Amazon Web Services 業務システム設計・移行ガイド (Informatics&IDEA)

Amazon Web Services 業務システム設計・移行ガイド (Informatics&IDEA)

  • 作者: 佐々木拓郎,林晋一郎,瀬戸島敏宏,宮川亮,金澤圭
  • 出版社/メーカー: SBクリエイティブ
  • 発売日: 2018/01/20
  • メディア: 単行本
  • この商品を含むブログを見る

iPad Pro + Smart Keyboard + Apple Pencilを 買いました

 執筆用のMacBook Air (Early 2014)のバッテリーがへたってきました。また、元々Retina対応ではないので、原稿の校正の時にPDFを見ようとしても拡大しないと見えないという問題がありました。年末くらいから悩んでいたのですが、iPad Pro(10.5インチ) + Smart Keyboard + Apple Pencilを買いました。

 

f:id:dkfj:20180129235149j:image

 

iPad Proを選んだ理由


 Macbookの買い替えでなく、iPad Proを選んだ理由はApple Pencilの存在です。プライベートの趣味である執筆活動の関係で、PDFになった原稿に赤入れする機会が多いです。現状、Macのプレビューの編集機能を使っているのですが、正直面倒くさいです。これ手書きでやりたいなぁということでiPad Proにしました。

 それ以上に、iPad Proでどこまでパソコンの代替になるか試してみたいという気持ちが強かったのも事実です。 

iPad Proにして良かった点

  Smart Keyboardの使い易さは、予想以上でした。過去、iPhone, iPad用のキーボードを3〜4個くらい買いましたが、まぁソフトウェアキーボードよりましかな程度でした。しかし、iPad Pro用のSmart Keyboardは、パソコンのキーボードとほぼ遜色がないレベルです。タブやコピー&ペーストをキーボード操作で実現できるのは、やっぱり楽です。※価格は、遜色がないレベルではなく、REALFORCE/Happy Hacking Keyboardレベルですが。。。

 Apple Pencilについても、手書き用途としては全く問題ないレベルです。私の汚い字を、ちゃんと再現してくれます。また、細かいタッチを微妙に補正する機能もあるようで、ハードとソフト面でいろいろ工夫しているのだなと垣間見れます。

 

f:id:dkfj:20180129233422p:image

 

 あとは、持ち運びやすさもいいですね。今回の選定基準の一つに、常にカバンに入れていても負荷が小さいというのもいれていました。今のところ、全く気にならないレベルです。

 

iPad Proで困っているところ


 逆にiPad Proで困っている点、つまりはMacbookより使い難い点をあげると沢山あります。入力一つにしても、悩むところは多いです。例えば、全角の空白をどう入れるかとか、行の先頭の英単語を勝手にに大文字にされるとか。それ以上に大きいのが、各アプリ側の対応。例えば、この記事は、はてなブログアプリで書いています。最低限の機能はあるものの、PC版の機能のフルセットではありません。結局、ブラウザの方を利用に切り替えたのですが、それでもスクロールにあわせた右の補助メニューの追付いのように、PCで出来ていることが実現できないことが多々あります。

 これは、Appleの問題というより各社の対応状況の問題です。利用者数から考えると、当面は解決の見込みはないでしょう。

 

これから試したいこと


 いろいろ不便なところがあるというのは、まぁ予想の範疇です。でも折角なので、iPad Proでしか出来ない使い方をいろいろ試してみようかなと思います。もともとMacbookも併用するというのは既定路線なので。Apple Pencilの活用以外としては、例えば音声入力ですかねぇ。

 

感想


 とりあえず半年後の自分への備忘録として書いてみました。1ヶ月、2ヶ月と使っていって、どう変わっていくか乞うご期待!!

一方で、下記については依然として自分の中でも消化できていません。

 

 

 

 

AWSにおけるネットワーク設計の真髄。Amazon Web Services 業務システム設計・移行ガイドにおけるネットワーク章

 早速Amazonで品切れになったAmazon Web Services 業務システム設計・移行ガイド です。個人的に最大の見どころは、4章のネットワーク接続の設計・構築・維持管理ではないかと思っています。

AWSにおけるネットワーク設計


 AWSにおけるネットワークサービスは、VPCを中心にDirect ConnectやRoute53、Internet GatewayやVPN Gateway,Nat Gatewayなど幾つものサービスがあります。ウィザードに沿って設定すると一通りの設定ができるものの、果たしてどのように設定するのがベストな設計なのか、ネットワーク設計の経験がないと難しいものがあります。また、AWSならではというハマりポイントもあるのも事実です。Amazon Web Services 業務システム設計・移行ガイド では、ネットワーク設計に必要な考え方をネットワーク面、AWSの機能面を含めて丁寧に説明しています。

4章のネットワーク接続の設計・構築・維持管理の執筆者


 というのも4章のネットワークに関する部分の執筆者は、NRIにおけるネットワークのスペシャリストである宮川亮さんの手によるものだからです。

パブリッククラウドのネットワーク基盤担当。2012年の東京リージョンへのAWS Direct Connect導入以来、多くのお客様への提案、構築、維持管理に従事。西日本でのリージョン開設やAWS Direct Connect Gatewayの開始によりニーズがさらに高まるのが楽しみ。好きなAWSサービスはもちろんAWS Direct ConnectとAmazon VPC。これからAWS PrivateLinkを好きになる予定。

 Amazonの著者ページにある略歴にあるとおり、2012年のNRIにおけるDirect Connectのサービスの提供以来、ずっとAWSのネットワークに関するサービスの中心にいました。数多くの企業にDirect Connectを提供し、或いはオンプレミスとAWSのネットワーク設計をし続けてきています。AWSのネットワーク設計をした数と規模では、間違いなく日本でも稀有の存在です。
 私も仕事の際には色々助けて貰ったことがあります。今回の執筆でも出来上がった原稿を見て、ネットワークの専門家はこんなことを考えながら設計するものなのだと、随分と勉強になりました。

ネットワーク設計ネタ


この章で取り扱ってるネットワーク設計のネタを幾つかピックアップします

・ダイレクトコネクトか、インターネットVPNか
・セキュリティグループとネットワークACLの使い分けのポイント
・ルーティング設計。BGPによる経路広報も添えて
・名前解決の問題
・インターネットへの出口をどうするか

この中でBGPの話などは、ネット上で情報が少ないので助かります。私もダイレクトコネクトについては、サービスとして提供されてるものを使う方なので、動的な経路設計などにいつも悩みます。その辺りの情報がひとまとめになっているのがありがたいです。

未来を占うコラム


 4章には、3つのコラムがあります。これが特に秀逸で、AWSのサービスに対する考察がなされています。

・「ダイレクトコネクトサービスはどれも同じ」ではない
・Direct Connect Gateway
・VPCエンドポイントの「ゲートウェイ」と「インターフェイス」

 ここは是非、本文読んでみてください。どのコラムも1ページ程度の分量なので、店頭での立ち読みでも直ぐに読めると思います。

まとめ


 身内で褒めるのも何ですが、AWS本でここまでネットワークについて書けている本は少ないと思います。最初の原稿見たときに、少し難しいすぎるかなと思ったものの、まとめて読んでみると全て必要な内容でした。ぜひ手にとって読んで頂きたいものです。

Amazon Web Services 業務システム設計・移行ガイド (Informatics&IDEA)

Amazon Web Services 業務システム設計・移行ガイド (Informatics&IDEA)

  • 作者: 佐々木拓郎,林晋一郎,瀬戸島敏宏,宮川亮,金澤圭
  • 出版社/メーカー: SBクリエイティブ
  • 発売日: 2018/01/20
  • メディア: 単行本
  • この商品を含むブログを見る


See also:
Amazon Web Services 業務システム設計・移行ガイドの目次
「Amazon Web Services 業務システム設計・移行ガイド」という本を書きました

Amazon Web Services 業務システム設計・移行ガイドのKindle版でました!!

 本日発売開始のAmazon Web Services 業務システム設計・移行ガイドですが、同時にKindle版も出ました。

Amazon Web Services 業務システム設計・移行ガイド 一番大切な知識と技術が身につく

Amazon Web Services 業務システム設計・移行ガイド 一番大切な知識と技術が身につく

  • 作者: 佐々木拓郎,林晋一郎,瀬戸島敏宏,宮川亮,金澤圭
  • 出版社/メーカー: SBクリエイティブ
  • 発売日: 2018/01/20
  • メディア: Kindle版
  • この商品を含むブログを見る

 残念ながら、全ページ画像の「固定レイアウト型」となっています。その為、ピンチイン・ピンチアウトなどの文字拡大や、ハイライトとかは付けられてません。著者としても何とかして欲しいところですが、技術書の市場規模を考えると余りコスト掛けられないという事情も解ります。版組の技術革新で何とかできないものですかね。

Amazon Web Services 業務システム設計・移行ガイドの電子立ち読み版


 税込みで3,456円とそれなりのお値段となっております。興味だけで買ってみるのはお財布に痛いと思います。今回は何故か、電子立ち読み版というのが出ています。最初の1章まるごと読めますので、内容が気になる方は是非読んでみてください。ただ1章については、サービス紹介など一般的な内容を載せざるをえなかったので、本書の特徴が出て来るのは2章以降です。何とか2章も載せてほしかったと思います。

r.binb.jp

Kindle版のメリット


 Kindle版は、かさばらないとか、持ち運びが便利などのメリットがあります。実はそれ以外にもあまり知られていないメリットがあります。本は改訂時に大幅に修正されます。また、増刷時にも細かい修正がされることが多いです。Kindle版であれば、一度購入すると無料で最新版を手に入れることができます。技術書の場合、これが嬉しいです。そんな訳で、私はもっぱら技術書もKindleで購入しています。もちろん紙の読みやすさは、まだまだ捨てがたいものあります。ぜひ、自分のスタイルにあったものをお選びください。


Amazon Web Services 業務システム設計・移行ガイド 一番大切な知識と技術が身につく

Amazon Web Services 業務システム設計・移行ガイド 一番大切な知識と技術が身につく

  • 作者: 佐々木拓郎,林晋一郎,瀬戸島敏宏,宮川亮,金澤圭
  • 出版社/メーカー: SBクリエイティブ
  • 発売日: 2018/01/20
  • メディア: Kindle版
  • この商品を含むブログを見る

See also:
Amazon Web Services 業務システム設計・移行ガイドの目次
「Amazon Web Services 業務システム設計・移行ガイド」という本を書きました

複数のAWSアカウント管理を制するものが、AWSを制する

 いよいよ明日発売開始であるAmazon Web Services 業務システム設計・移行ガイドの一貫したテーマが、「企業内でどのようにAWSを使っていくのか」です。企業内でのユースケースを元に、ネットワーク/システム設計や運用管理、移行の話をしています。その中で1章を割いて説明しているのが、AWSアカウントをどのように管理するかです。

複数(マルチ)AWSアカウント管理の重要性


 AWSを利用する上で、AWSアカウントをどのように管理していくかは最重要事項です。AWSアカウント管理というと、一般的には、AWSリソースの認証認可であるIAMを使った運用方法について語られることが多いです。しかし、企業内で利用する際は、それだけでは不十分です。何故なら、企業内では1つのAWSアカウントではなく、複数のAWSアカウントを作成し運用することになるからです。いわゆるマルチアカウント運用です。
 企業内での運用がマルチAWSアカウントとなる理由は、主に管理上のメリットです。現状のIAMの機能では、サービス単位の管理が基本となります。リソース単位の権限管理も可能ですが、安全簡単に設定できるという構造にはなっていません。例えば、EC2のインスタンス管理について考えてみましょう。開発者と運用者というロールがあるとして、開発環境は開発者が管理し、本番環境は運用者が管理するとします。この場合、開発者は本番環境のインスタンスの操作はできないようにしないといけません。現状のIAMの機能では、これを実現するにはIAMの設定中に具体的なりソース名(インスタンスID)を列挙していくしかありません。また、インスタンスの一覧から権限がないものについて見えなくするというようなことも出来ません。
 現実的にはIAMのみでの運用は難しいので、本番環境用のAWSアカウントと開発環境用のAWSアカウントを分離することになります。これがマルチアカウント化の第一歩です。次に組織別のAWSアカウントです。一定以上の規模であれば、複数のサービス・プロジェクトを運用していることでしょう。また企業内の組織構造も、そのミッションに従って本部/部/室などの単位で別れていると思います。ここで、AWSのアカウントを組織横断で運用できるかという問題がでてきます。横串にAWSアカウントを管理するような組織があれば可能かもしれませんが、現実的には余り実現していません。
 結果的に、AWSアカウントは組織ごと環境ごと作成されることになります。つまり1つの企業内にAWSアカウントが10も20もあるというのが当たり前の状況なのです。これを何も考えずに放置していると、それぞれの組織毎に同じようなことに頭を悩ませ、試行錯誤することになります。それを回避するには、最初に下記のようなことを考える必要があります。

・AWSのアカウント管理方法
・AWSアカウントをどの単位で分割するべきか
・IAMの権限付与設計

 こんなようなことを考えていくのがアカウント管理設計ですね。

f:id:dkfj:20180119072331p:plain

AWSのアカウント管理方法 には、AWS Organizations


 現状のAWSの機能でいうとAWSのアカウント管理には、AWS Organizationsを使うことになります。これは名前の通り、組織内で利用するAWSアカウントを管理する為の機能が提供されています。AWS Organizationsを使うことにより、アカウントのグループ化であったり、アカウントで利用できる機能の制限することができます。また、このサービスについては従来の一括決済機能の発展的な部分があり、請求を一つにまとめるということができます。概念図としては、次のような形になっています。

f:id:dkfj:20180119072307p:plain

 このAWS Organizationsについて、どう使っていくのか明確な指針を出せている所は少ないと思います。例えば、サービスコントロールには、ブラックリスト方式とホワイトリスト方式の2種類があります。また、制限をかける範囲をrootからにするか、Organization Unit単位にするかなどの選択肢があります。この辺りについて、Amazon Web Services 業務システム設計・移行ガイドの3章で重点的に解説しています。

マルチアカウント化したものの


 一方でマルチアカウント化したら、それで全て解決かというとそうでは無いのですよね。例えば、ネットワーク接続をどうするかなどの問題があります。2017年末にDirect Connect Gatewayが出て、専用線を使った複数VPCの接続方法が柔軟にできるようになりました。ただし、現状では別アカウントのVPCを接続できません。或いは、AWS Systems Managerという機能がでてEC2やRDSをグルーピング化できるようになりました。これで権限管理も出来ないかなぁとか色々思うところもあります。
 組織が違えば運用形態も違うので、ただひとつの正解というのは無いと思います。その中で、比較的ベスト・プラクティスに近いのを集めて行ければなぁと思っています。ということで、Amazon Web Services 業務システム設計・移行ガイドは明日発売です!!

Amazon Web Services 業務システム設計・移行ガイド

Amazon Web Services 業務システム設計・移行ガイド

  • 作者: NRIネットコム株式会社:佐々木拓郎,林晋一郎,株式会社野村総合研究所:瀬戸島敏宏,宮川亮,金澤圭
  • 出版社/メーカー: SBクリエイティブ
  • 発売日: 2018/01/20
  • メディア: 単行本
  • この商品を含むブログを見る

See also:
Amazon Web Services 業務システム設計・移行ガイドの目次
「Amazon Web Services 業務システム設計・移行ガイド」という本を書きました

JAWS-UG さいたま支部で、「サーバーレス化を支える認証認可の話」という話しをしてきました。

 1/13にJWAS-UGさいたま支部第9回で、「サーバーレス化を支える認証認可の話」という話しをしてきました。

サーバーレス化を支える認証認可の話


 API GatewayやCognitoを利用する際にAWSの機能でどんな認証方法があるのか、あるいはアクセス制限ができるのかという話しをまとめています。認可の話しは全くしていないので、ちょっとタイトルを盛りすぎたと反省しています。

speakerdeck.com

この話の背景


 最近、フィンテックだなんだでシステムをAPI経由で利用できるようにして、外部公開したいという話しが増えています。その際に聞かれることが多い事例を挙げています。個人的な印象だと、認証とアクセス制限をごっちゃにしている人が多いのですね。またアクセス制限についての相談も多いです。個人的にはアクセス制限は気休めの場合が多いので、そこから考えるのは悪手だと考えています。一方で、既存のシステムとのセキュリティポリシーとの兼ね合いで、対応せざるを得ないという事情も解ります。ということで、悩む前にこれ読んでもらって、調べる時間が短縮されればと思います。

認可の話


 資料書いているうちに、アクセス制限の方に頭がいって認可の話しを書くのを忘れていました。どこかのタイミングで追記しようと思います。簡潔にまとめると、IAMはユーザーとAWSリソースの認証認可のサービスなので、これを使ってアプリケーションの認証認可に使うのは向いていません。Cognitoのフェデレーション機能使ってトークンの運用を楽にして、アプリケーションの認可は自分で作り込むという形になります。このあたりの話しに需要があれば、ブログ等でまとめたうえで電子書籍化してみたいなと思っています。ベースは2年前くらいに考えていた、この記事になります。
AWSとシステムの認証認可を考える

まとめ


 久しぶりのJAWSUGの登壇でした。準備不足で痛い目にあいましたが、やっぱり楽しいですね。去年サボったので、今年は対外発表を頑張ろうと思っています。お気軽にお声がけください。
 あと最後に宣伝ですが、Amazon Web Services 業務システム設計・移行ガイドが今週発売です。こっちはAWSのアカウント管理とかネットワーク設計、データ移行とオンプレミスと正面から向き合った1冊です。ぜひぜひギャップを楽しんでください。

Amazon Web Services 業務システム設計・移行ガイド

Amazon Web Services 業務システム設計・移行ガイド

  • 作者: NRIネットコム株式会社:佐々木拓郎,林晋一郎,株式会社野村総合研究所:瀬戸島敏宏,宮川亮,金澤圭
  • 出版社/メーカー: SBクリエイティブ
  • 発売日: 2018/01/20
  • メディア: 単行本
  • この商品を含むブログを見る


See also:
Amazon Web Services 業務システム設計・移行ガイドの目次
「Amazon Web Services 業務システム設計・移行ガイド」という本を書きました

Amazon Web Services 業務システム設計・移行ガイドの目次

 お正月に筆者陣にてAmazon Web Services 業務システム設計・移行ガイドの最終校正をおこなっていました。これで私の作業は終わりで、後はいよいよ発売を待つ限りです。発売日は、2018年1月20日の予定です。目次も確定したので、細かい部分含めて公開します。

Amazon Web Services 業務システム設計・移行ガイドの目次


Chapter1 AWSサービスの概要
1-1 AWSとは
 AWSのサービスの特徴
 AWSとオンプレミスの違い
  ・所有と利用
  ・キャパシティ設計
  ・クラウドサービスの見分け方
 AWSのメリット
  ・スモールスタートで始められて、駄目だったら捨てられる
  ・インフラ構築のスピードを加速できる
  ・事前に多めのリソースを確保する必要がなくなる
  ・AWSのメリットは、「早めに失敗する」が可能なこと
1-2 AWSのサービスの全体像
 AWSの基本的な考え方
 リージョンとアベイラビリティーゾーン
  ・リージョン
  ・アベイラビリティーゾーン
 VPCとDirect Connect
  ・VPC
  ・Direct Connect
 AWSアカウント
  ・単一アカウント
  ・複数アカウント
 AWSでの監査証跡
  ・AWSにおける監査証跡の対象
 AWSの料金
  ・AWSの料金体系
  ・AWSの無料枠
  ・AWSの料金計算ツール「Simple Monthly Calculator」
  ・一般的な構成での利用料金の内訳
1-3 主なAWSサービス
 コンピューティングサービス
  ・仮想サーバ「EC2」
  ・サーバレスなコンピュータ処理基盤「Lambda」
 ストレージサービス
  ・オンラインストレージボリューム「S3」
  ・ファイルストレージボリューム「EFS」
  ・S3へのデータ転送機能「Storage Gateway」
 データベースサービス・データ処理サービス
  ・Amazon RDS
  ・AWSのNoSQLサービス
 ネットワークサービス
  ・プライベートネットワーク機能「VPC」「Direct Connect」
  ・DNSサービス「Route 53」
  ・CDNサービス「CloudFront」
 AWSの管理ツール
  ・テンプレートによる自動構築ツール「CloudFormation」
  ・AWSの利用状態の管理ツール「CloudTrail」「Config」
  ・サポートサービス「Trusted Advisor」「AWSサポート」
 AWSへ移行するためのサービス
  ・データ移行サービス「DMS」
  ・大量データの持ち込みサービス「Snowball」
 アカウント管理
  ・AWSのアカウントの種類
  ・AWSアカウント
  ・IAMユーザー
  ・組織アカウント(AWS Organizations)
 セキュリティツール
  ・継続的セキュリティ評価ツール「Inspector」
  ・無料のサーバ証明書発行ツール「Certificate Manager」
  ・DDoSやアプリケーションレイヤーの防御「WAF」「Shield」
 通知&監視サービス
  ・通知サービス「SNS」
  ・監視サービス「CloudWatch」

Chapter2 全体設計(管理方針と移行計画)
2-1 アカウントの管理の考え方
 AWSアカウントとIAMユーザー
  ・AWSアカウント
  ・IAMの構造
  ・一時的な権限付与とクロスアカウントロール
 複数のAWSアカウントを管理する
  ・一括請求機能「Consolidated Billing」
  ・組織アカウント(AWS Organizations)
2-2 AWSと監査証跡
 システムのログ・操作履歴
 AWSのログ・操作履歴
2-3 AWSのネットワーク設計の考え方
 VPCの位置づけと社内ネットワークとの接続方法
  ・社内ネットワークの形態
  ・VPCをどう接続するか
  ・拠点とVPCの接続
 複数のAWSアカウント間の接続方法
  ・用途別のAWSアカウントの分類と接続方法
  ・VPCピアリングを利用したAWSアカウント間の接続
2-4 AWSへのシステム移行
 クラウドジャーニー:移行のステップ
 AWS移行のパターン
  ・単純移行
  ・カスタマイズ
  ・最適化
 AWSへの移行計画
  ・フィット&ギャップ分析
  ・導入コンサルティング(AWSプロフェッショナルサービス)
  ・机上検証は最小限に
 AWSの移行サービス
  ・サーバの移行
  ・データの移行
  ・データベースの移行
2-5 AWS上のシステムの監視・運用
 AWS上のシステムの監視の考え方
  ・システムの監視対象
  ・CloudWatchを使った監視
  ・SNSを使った通知
 AWSの運用サービス
  ・インスタンスの状態管理・運用「Systems Manager」
  ・インスタンスのセキュリティ評価「Inspector」
  ・サポートサービス

Chapter3 アカウント管理と権限付与
3-1 AWSのアカウント管理
 効率的にアカウントを管理する
 AWS Organizations
  ・AWS Organizationsを用いたAWSアカウントのグルーピング
  ・AWS Organizationsの機能
  ・アカウントの作成
  ・請求の一元管理
  ・アカウントで利用するAWSサービスに制限をかける
  ・JSON形式の権限設定
  ・ポリシージェネレータ
 AWS Organizationsの導入とポリシーの設定
  ・マスターアカウントでOrganizationを作成
  ・Organizationに紐付けるアカウントの設定
  ・Organization Unitの作成と階層構造の定義
  ・サービスコントロールポリシーの作成とアタッチ
 AWS Organizationsのベストプラクティス
  ・マスターアカウントでCloudTrailを有効にする
  ・マスターアカウントはアカウント管理専用にする
  ・Organization Unitにサービスコントロールポリシーをアタッチして権限を制限する
・Organization内でホワイトリストとブラックリストを混在させない
 アカウント管理のロードマップ
  ・管理主体と管理する範囲を決定する
  ・Organizationを管理する担当を決定する
  ・権限付与のルールを作成する
  ・Organization Unitの構成設計を行う
3-2 AWSの環境分離
 環境をアカウントで分割するメリット
  ・運用面のメリット
  ・コスト管理におけるメリット
 環境をアカウントで分割するデメリット
  ・運用面のデメリット
  ・コスト面のデメリット
 特別なポリシーがない場合の分割のベストプラクティス
3-3 AWSの権限管理
 IAM(Identity and Access Management)
  ・IAMポリシー
  ・IAMポリシーの作成
  ・IAMユーザーとIAMグループ
  ・rootユーザーの扱い
 マネジメントコンソール以外からAWSサービスを操作する
  ・アクセスキーとシークレットキーを用いて、AWSリソースを操作する
  ・アクセスキーとシークレットキーの作成
  ・CLIのインストール
  ・CLIの設定(アクセスキー・シークレットキーの設定)
  ・AWSリソースへのアクセス
 キー漏洩の対策
  ・IAMロール
 Amazon Cognito
  ・Cognito Identity
  ・Cognito Identityを用いた認証と認可の流れ
  ・User Pools
  ・Federated Identities
  ・Cognito Sync
 AWSにおける権限管理のベストプラクティス
  ・役割ごとのIAMグループで権限を管理する
  ・利用者ごとにIAMユーザーを払い出す
  ・割り当てる権限は、必要最低限のものにする
  ・権限やIAMユーザーについては定期的に棚卸しし、最適な状態を保つこと
  ・その他、これまでに記載してきた下記のルール

Chapter4 ネットワーク接続の設計・構築・維持管理
4-1 AWSネットワークの全体構成
 AWSネットワークの構成要素
  ・VPC
  ・インターネットにおけるAWSサービスへの接続
 通信要件
  ・通信内容の整理
 物理構成
  ・VPCの位置づけ
  ・VPCをどこに接続するか
  ・インターネットをどこに接続するか
 論理構成
  ・アドレスアサイン
  ・VPCが幾つ必要か
 サービスの選定
  ・インターネットVPN
  ・Direct Connect
4-2 ネットワーク設計
 アドレス設計
  ・VPCに割り当てるCIDRブロック
  ・サブネット
 ルーティング設計
  ・AWSのルーティング要素
  ・ルートテーブル
  ・local
  ・インターネットゲートウェイ(Internet Gateway)
  ・VPNゲートウェイ(Virtual Private Gateway:VGW)
  ・ピアリング接続
  ・稼働中のEC2インスタンス
  ・VPCエンドポイント
 フィルタリング設計
  ・ルーティングによるフィルタリング
  ・VPCのフィルタリング機能を用いたフィルタリング
 名前解決とDHCPオプションセット
  ・グローバル(インターネット)への名前解決の必要性
 ロードバランサー設計
  ・ELBのメリット・デメリット
  ・仮想アプライアンスのメリット・デメリット
  ・ELB(ロードバランサーサービス)
  ・ELBの基本的な機能
  ・ELB利用時のポイント
 パケットキャプチャとVPCフローログ
 Route 53
  ・権威DNSサーバ機能
  ・ルーティング機能
  ・ヘルスチェック機能
  ・ドメインの登録(取得)

Chapter5 システム設計とサービスの導入
5-1 AWSサービスを利用したシステム設計
 オンプレシステムとの連携を伴わないECサイト
  ・アカウント
  ・VPC、サブネット
  ・Webサーバレイヤー
  ・データベースレイヤー
  ・バッチサーバ
 ハイブリッド環境で運用する基幹システム
  ・インターネット接続とセキュリティ
  ・紹介するアーキテクチャパターン
5-2 Web可用性向上パターン
 ELB
  ・ELB自体のスケーリング
  ・ヘルスチェック機能
  ・スティッキーセッション
  ・Connection Draining
 Auto Scaling
  ・Auto Scalingの設定項目
  ・Auto Scalingグループ
  ・起動設定
  ・Scalingポリシー/プラン
 Web可用性向上パターン
  ・パターン導入のポイント
 ELBとAuto Scalingの利用方法
  ・ELBの利用方法
  ・Auto Scalingの利用方法
  ・Auto Scaling設定の確認
5-3 コンテンツキャッシュパターン
 Amazon CloudFront
 CloudFrontとAWSサービスの連携
  ・各種セキュリティサービスとの連携
  ・Amazon API Gatewayとの連携
  ・Lambda@Edgeとの連携
 コンテンツキャッシュパターン
  ・キャッシュTTLを正しく設定する
  ・Popular Object Reportを参考に定期的に設定の見直しを行う
  ・オリジンサーバの障害を考慮した設計を行う
  ・CloudWatchを設定してアラームを受け取る
 CloudFrontの利用方法
  ・S3の静的ホスティングの設定
  ・CloudFrontの設定
  ・CloudFrontの設定の確認
5-4 DB可用性向上パターン
 RDS
  ・RDSを用いるメリット
  ・RDSを用いるデメリット
  ・「RDS」vs「. DB on EC2 with CLUSTERPRO」
 DB可用性向上パターン
  ・運用のポイント
  ・マスター・スレイブ構成にすることでメンテナンス時間を短くする
 RDSの利用方法
  ・マルチAZにマスターDBとスレイブDBを配置する
5-5 インメモリキャッシュパターン
 ElastiCache
  ・ElastiCache for Memcachedの特徴
  ・ElastiCache for Redisの特徴
 インメモリキャッシュパターン
  ・導入する際のポイント
 ElastiCacheの利用方法
  ・Memcachedの作成
  ・Memcachedの設定
5-6 ジョブサーバパターン
 ジョブサーバパターン
  ・構築のポイント
 NATゲートウェイの利用方法
  ・NATゲートウェイの作成
  ・ルートテーブルの編集
 VPCエンドポイントの利用方法
  ・VPCエンドポイントの作成
  ・VPCエンドポイントの設定
5-7 ハイブリッド利用パターン
 インターネット接続設計
  ・VPC内からインターネットへアクセス
  ・サブネット設計
 ハイブリッド利用パターン
  ・AWS環境への移行方法
  ・システムの一部をAWS環境に移行するパターン
  ・システム全体をAWS環境に移行するパターン
5-8 ファイルサーバ利用パターン
 ファイルサーバ利用パターン
  ・全体の構成
  ・ネットワーク設計
 Storage Gatewayの利用方法
  ・ファイルゲートウェイサーバの作成
  ・バックアップ先のS3の設定
  ・クライアントからファイルゲートウェイをNFSマウント
  ・注意事項
5-9 大規模データ分析パターン
 RedshiftとBIツールを利用した大規模分析
 大規模データ分析パターン
 Redshiftの利用方法
  ・サンプルデータのS3アップロード
  ・テーブルの作成とデータのインポート
  ・サンプルデータのロード
  ・BIツールからのRedshift接続
5-10 インフラ構築を自動化する
 AWSのインフラ構築自動化サービス
  ・AWS CloudFormation
  ・AWS OpsWorks
  ・AWS Elastic Beanstalk
  ・サービスの使い分け
 CloudFormationを用いたインフラ自動構築
  ・CloudFormationの機能概要
  ・CloudFormationの組み込み関数
  ・セクション 268 CloudFormationのベストプラクティス
  ・セキュリティ面のベストプラクティス
  ・テンプレート設計・作成面のベストプラクティス
  ・運用面のベストプラクティス
 AWS OpsWorks
  ・OpsWorksスタック
  ・OpsWorks for Chef Automate
 AWS Elastic Beanstalk
  ・All at Onceデプロイ
  ・Rollingデプロイ
  ・Rolling with additional batchデプロイ
  ・Immutableデプロイ
  ・URL Swapでの切り替え
  ・Route 53での切り替え

Chapter6 移行テクニック
6-1 移行する資産
6-2 データの移行
 データ移行にかかる時間の目安
 AWSのサービスを使わないデータ移行
  ・OSコマンドを使ったデータ移行
  ・CLIを使ったデータ移行
 AWSのサービスを使ったデータ移行
  ・Storage Gatewayを使う
  ・Snowballを使う
  ・Snowball Edge
  ・Snowmobile
6-3 仮想サーバを移行する
 AWS Server Migration Service
  ・SMSの構成概要
  ・VM Import/Exportとの違い
  ・SMSの特徴
  ・OSのライセンス
6-4 データベースを移行する
 AWSのサービスを使わずにデータベースを移行する
 AWS Database Migration Service
  ・DMSの構成概要
  ・DMSとオンプレミスサーバ間の接続経路
  ・同一データベースシステム間の移行
  ・異なるデータベースシステム間の移行
  ・データの移行と移行後のデータ同期

Chapter7 運用監視の設計・実施
7-1 システムを監視する
 CloudWatchを使う
  ・標準のメトリクスで監視する
  ・カスタムメトリクスを使って監視する
  ・オンプレミスサーバの監視との比較
  ・AWS特有の監視
 CloudWatch Logsを使う
  ・エージェントのインストール
  ・監視対象ログの設定
  ・エージェントの起動
  ・CloudWatch Logsへ転送されたログの確認
  ・特定文字列の検知
  ・CloudWatch Logsの他サービス連携
 CloudWatch Eventsを使う
  ・EC2インスタンスのスケジュールイベント通知
  ・イベントバス
7-2 システムを運用する
 AWSサポート
  ・インフラストラクチャイベント管理(IEM)
  ・サポートへの問い合わせ方法と応答時間
  ・リソース制限の増加申請
  ・サードパーティ製ソフトウェアサポート
 AWS Personal Health Dashboardを使う
 AWS Trusted Advisorを使う
  ・チェック結果の通知
  ・サービス利用制限のチェック
 Amazon Inspectorを使う
  ・Inspectorの実行
 Amazon EC2 Systems Managerを使う
  ・SSMが提供するサービス
7-3 システムの履歴を管理する
 AWS CloudTrailを使う
  ・CloudWatch Logとの連携
  ・CloudTrailを設定する
 AWS Config/Config Rulesを使う
  ・サービス連携
  ・ルールの作成
  ・Configを設定する
  ・履歴の確認

Amazon Web Services 業務システム設計・移行ガイドの目次の解説



1章 AWSサービスの概要

 1章は、AWSの基本的な考え方やサービスの説明です。オンプレに較べてのAWSや、リージョンやアベイラビリティゾーンなど基本的な概念から、AWSアカウント・ネットワーク・料金体系など一番基本的な部分を説明の上で、主要なサービスを説明しています。注目して欲しいのが、ピックアップしたサービスです。EC2やS3、RDSというお馴染みのもの以外にも、Snowball・DMS・AWS Organizations、Inspectorなど余り耳にする機会が少ないものもあります。これは、企業内で導入する際には是非抑えておいて欲しいサービスを選んだ結果です。この辺りのサービスを解説している書籍は、結構少ないのではと思っています。

2章 全体設計(管理方針と移行計画)

 2章は全体設計ということで、本書の基本的な考え方を紹介しています。AWSアカウント管理、監査証跡、ネットワーク設計、システム移行、監視・運用の5つの節で構成されています。ここで概要を説明した上で、後の章で個別・具体的に構築方法含めて紹介しています。

f:id:dkfj:20180108162954p:plain

3章 アカウント管理と権限付与

 3章からがメインのコンテンツです。3章は、AWSのアカウントの管理でAWS Organizationsからアカウント分割の方針、IAM・Cognitoと紹介しています。ここでは概念だけではなく、具体的な設計、ポリシー例を挙げたいます。AWS Organizationsについては、基本的な機能から具体的なサービス制限の仕方、ベストプラクティス等にも言及しています。何とAWSのアカウントだけで、50ページを割いているいます。

f:id:dkfj:20180108162448p:plain

4章 ネットワーク接続の設計・構築・維持管理

 4章はAWSにおけるネットワーク設計です。AWS内のVPC内に留まらず、オフィス・データセンターと全体がある中で、AWSのネットワークをどう位置づけるか、その視点での設計の紹介となっています。AWS本は数あれど、この視点で解説している本は少ないと思います。ここの部分を、2012年からAWS Direct Connect ソリューションプロバイダーとしてサービスを運用・提供してきた実担当者によって、詳しく解説されています。世の中、Direct Connectを使ったことがある人は数多くいると思いますが、Direct Connectのサービスを提供している人は殆どいません。そういった意味で、現場での知識・ノウハウが沢山散りばめられています。

f:id:dkfj:20180108162150p:plain

5章 システム設計とサービスの導入

 5章は具体的なシステム設計です。企業内で使われることが多い構成を念頭に、どのように設計するのがよいのかパターン別に紹介しています。AWS単体の設計のみならず、オンプレミスとのハイブリッド構成の場合どうするかといった事が随所に書かれています。一番ニーズの多い、WebサーバやDBサーバの可用性やスケーリングの方法、大規模運用であれば欠かせないコンテンツキャッシュなどWeb寄りの話から、ジョブサーバやファイルサーバ、或いはハイブリッド構成の場合にどのようにインターネットに接続させるかなど実用的なテーマもあります。それ以外にも、Redshiftによる大規模データ分析や、AWSのサービスを利用したインフラ構築の自動化など、様々なテーマがあります。この章が読んでて一番楽しい部分だと思います。

f:id:dkfj:20180108165722p:plain

6章 移行テクニック

 6章は一転して、移行の話です。多くの場合、企業内のシステムは新規で一から作るのではなく、既存のシステムからの移行、或いは連携が必要になってきます。もっと言うと、データをどう移行するのか。そういった時に直面するのが物理の壁です。例えクラウドサービスといえども、何十TBのデータを一瞬で移行することは出来ません。物理的なファシリティの制約を受けます。例えば、既存のデータセンターの回線が100MBとすると、その回線を専有したとしても10TBのデータを移行するのに1週間以上掛かる訳ですね。現実的には、専有は出来ないし、1週間システムを止めておける訳でもないのでドンドン差分データが増えていきます。
 では、どうしたら良いのかというのを、あの手この手で解説しています。主にデータの移行・仮想サーバの移行・データベースの移行の3つに別けられていますが、根底とする部分は同じです。サービス止めないで、システム移行してねとサラッと言われ続けてきた辛みに対するノウハウの結集です。

7章 運用監視の設計・実施

 最後の7章は、AWS上にシステムを構築/移行した後の運用を見据えた話です。オンプレの運用監視と何が同じで違うのか、その視点での説明です。CloudWatchなど比較的お馴染みの話から、AWSサポートの使い方やTrusted Advisorなど運用始まったら必ず使うサービスや、Inspector, EC2 System Managerなどこれから主流になっていくサービスにも言及しています。

感想


 改めて目次を見返すと、我ながらよくまとまっていると思います。この内容は、私一人では決して書けなかったです。AWSの各分野のプロフェッショナルが集結した結果、この本が出来上がったと思います。最後にはなりますが、AWSの設計をする上で、ただ1つの正解というのはありません。利用者を取り巻く環境・制約によって、最適な解は変わってきます。本書では、その前提に立ちつつも、できるだけ多くの人に役立つよう企業への導入時のあるあるを思い出しながら書いています。是非、みなさん読んでみて感想きかせてください。


See Also:
「Amazon Web Services 業務システム設計・移行ガイド」という本を書きました
「この一冊で全部わかるWeb技術の基本」の監修をしました
「データを集める技術」という本を執筆しました
アプリケーションエンジニア向けのAWS本を書きました
『Amazon Web Services パターン別構築・運用ガイド』を書きました
『Rubyによるクローラー開発技法』を書きました