JAWS-UG首都圏勉強会レポート 第5回

第6回初心者支部はイントロセッションも見逃せない

AWS初心者がまず知っておきたいこと、ハンズラボ吉田さんが語る

6月28日、銀座のD2Cのイベントスペースにおいて第6回となるJAWS-UG初心者支部が開催された。登壇したハンズラボの吉田裕貴さんは、AWSの学習方法やAWS利用で基本となるDesign For Failureや責任共有モデル、アカウントの管理などについて丁寧に説明した。

7～8割が初参加！大型会場で盛り上がる勉強会

　昨年立ち上がったJAWS-UG初心者支部の勉強会もすでに6回目を数える。会場となったD2Cのイベントスペースはコミュニティの勉強会の会場とは思えないほど広大で本格的。19時からスタートしたイベントには、会場の広さに負けない80名近くの参加者が集まった。冒頭、登壇したJAWS-UG広報の青木由佳さんが参加者に挙手を求めたところ、なんと7～8割近くが初めての参加だった。

JAWS-UG広報のハンズラボ青木由佳さん

　会場提供のD2Cに謝辞を述べた青木さんはJAWS-UG初心者支部について「初心者支部なので、AWS初めてという人はもちろん、講師やLTデビューもお待ちしております」と説明。JAWS-UG on ASCIIの開始や首都圏の支部が勢揃いした5月末のJAWS-UG東京の開催などを報告しつつ、公式サイトにJAWS-UGの勉強会カレンダーをアピールした。

AWSを学ぶにはここからスタート

　「好きなサービスはLambdaとCloud Front。サーバーの管理はつらいのでやりたくない。好きが講じてAWSについて話しています」と自己紹介したハンズラボの吉田裕貴さん。後に続くAWS導入座談会の前知識ということで、AWSの概要について解説した。

ハンズラボの吉田裕貴さん

　AWSのサービスは数が多い。マネジメントコンソール上で確認できるサービスだけで56個で、このほかCLIのみで扱えるサービスもかなりある。これだけサービスがあるので覚えるだけで大変。まして使いこなすのは骨が折れる。そのため、「だから一度に覚えるのではなく、EC2やRDB、AutoScaling、ELBなどよく使われる構成のサービスから覚えていくのがよい」と吉田さんはアドバイスする。

　とはいえ、公式トレーニングは高価。そのため、AWSの書籍を読んだり、他支部の勉強会資料に目を通したり、水曜日の夜に開催されているWebセミナーである「AWS Black Belt」を活用するのがオススメ。「AWS CLI専門支部ではハンズオンの資料がQiitaで公開されている。試してみると、本当に同じことができるので、ぜひチェックしてほしい」（吉田さん）。

公式トレーニングに行かなくても、AWSを学ぶ方法をいくつもある

　また、トレーニング資料や個別サービス資料が大量に掲載されているAWSJの「AWSクラウドサービス活用資料集」も参考になるという。さらにエンジニアが積極的にブログを公開しているので、最新情報をキャッチアップするのに役立つ。

Design For Failureやクレデンシャルキーの扱い

　続いて吉田さんはAWSのようなクラウドサービスで重要ないくつかの考え方を説明した。1つ目は障害発生を前提としたシステムを構築する「Design For Failure」だ。

構成の多重化を意識する「Design For Failure」の考え方

　Design For Failureは、クラウドにおいても、オンプレミスと同じDR対策・多重化構成を持つべきという考え方だ。吉田さんは、オーストラリア東部で起こった大雨により、AWSをホストするデータセンターの電源設備がダウンしたという事例を紹介。クラウドというと堅牢なイメージがあるが、障害自体はやはり起こるため、それに備えた対策が必要になるという。

　もともとAWSでは地理的に離れたリージョンの中に、複数のデータセンターから構成されるアベイラビリティゾーン（AZ）が存在しており、AZは高速なネットワークで接続されている。AZ同士は災害等のリスクを考慮して物理的に離れた距離にあるため、「先ほどのオーストラリアの障害も単一AZ障害で済んでいる」（吉田さん）とのこと。しかし、AZをまたがるマルチAZ構成をとれば、サービスは止まらないため、クラウドにおいても冗長化構成が重要になるという。

AZレベルの多重化を施せば、単一AZ障害にも耐えうる

　2つ目として吉田さんが指摘したのは、AWSの各サービスにCLIでアクセスするためのクレデンシャルキーの扱いだ。秘匿性の高いこのキーをGitHubに載せてしまう事故が最近多発。キーを悪用されてしまうと、巨大なインスタンスを限界までぶん回されてしまい、数十万～数百万という料金が請求されることもあるという。「クラウド破産に至る。個人で使っている人は本当に怖い」（吉田さん）。

　そのため、公開する資料やソースコードにはキー情報を書き込まないよう徹底。とはいえ、人の注意には限界があるため、git-secretなどAWSが公開しているツールを使って、コミット前に検査することを推奨した。

クレデンシャルキーは絶対に資料やソースコードに書き込まない

ベストプラクティスのありかと責任共有モデル

　さらに吉田さんはAWSのベストプラクティスについてはAWS Summitで配布された「事例大全集」が参考になると説明。「AWSで公開されている127事例が全部出ていて、よくまとまっている。構成図を眺めて、エンタープライズシステムってこうやって動くのかと参考になる」（吉田さん）とのこと。逆にやってはいけないことを集めたアンチパターンもAWSのブログ等で積極的に公開されているため、両者を身につけることで、実践的な導入・構築が可能になると言う。

　そして、吉田さんが説明したのが、AWSとユーザーの責任分界を示した「責任共有モデル」の解説。セキュリティの観点では、物理セキュリティやネットワーク、仮想マシンのレベルはAWS側が責任を持つが、クラウド内のセキュリティ設定や管理はユーザー側が責任を持つ。具体的にはOSやアプリケーション、ファイアウォールなどはユーザーの管轄となる。

責任共有モデルの概要

　「簡単に言うと、ユーザーが触れないところはAWSが責任を持ってやってくれる。いくら物理レベルでさまざまな監査や規格を取得していても、上位のOSやアプリケーションが脆弱だと意味がない。上の方が僕たちがきちんとやっていかないとならない」と吉田さんは指摘した。

　特に重要なのはAWSアカウントの管理。多要素認証を使って、認証の強度を上げるほか、「IAMユーザーを作成し、ルートアカウントは使わない」「必要最低限の権限しか付与しない」「大文字・小文字・特殊文字の利用などパスワードポリシーを厳格に適用する」などをきちんとやってもらいたいと参加者に呼びかけ、あとのAWS導入座談会に続けた。

■関連サイト

• JAWS-UG初心者支部（Compass）