AWSの概念・全体像 M3 社内研修用 エンジニアリンググループ 園田

アジェンダ 今日話すこと: AWSの理解を早めるための考え方（DDDを添えて） 今日話さないこと: AWSとは、クラウドとは（本来予定していたのはコレ） 各サービスの説明（ちょっとは話すけど） AWSの構成事例など実践的なこと

AWSJの方に相談したら資料提供いただきました 私「来週に社内向けのAWS講義を予定しているのですが、日本語の公開資料などで適 切なものはありますでしょうか。」 AWS担当者様「ズバリな資料はありませんが、添付＋こちらのAWS発の資料が一定の ご回答になるかと思います」 ● クラウドにおけるアーキテクチャの設計原則 (オススメ!!) ○ AWSに限らず、クラウドアーキテクチャについてとてもよくまとまっています。 ○ インフラ全般に言えることでもあるので詳しくない人は一読する価値あります。 ● AWS Summit 2017 セッション資料一覧 (各社の事例集) ● AWS クラウドサービス活用資料集 (サービス別Tips)

大前提として AWSを知る上で最も効果的で最も重要なことは「実際に使ってみること」です。SAさんも みんなこう言います。（AWSに限った話ではないですが） ですので、もし時間とお金が許すのであれば、素人の講義を聞くよりも実際に手を動か してみてください。 そうは言っても、お金は１円も払いたくない、という人も多いと思いますので、今回はそう いった方々向けにお金をかけずに（時間はかかります）効率よくAWSを知るためのTips を紹介します。 ※ ちなみに私（園田）の個人AWSアカウントは月額$0.05くらいです。

AWSのサービスや機能は膨大 私はこの頃 S3, SQS

AWSのサービスや機能は膨大 昔からAWSを触っている人なら問題ないですが、新しくAWSを触り始める人にとっては 何から手を付けていいのか、何を覚えればいいのか、迷子になる人が多いです。 本スライドでは、そういった人たちの手助けになるよう、AWSのサービス機能を理解する ために必要な考え方を中心に解説したいと思います。 AWSを利用するためにすべてのサービスを理解する必要はないということだけは念頭 に入れておいてください。

ぜひ資料も読んでください 先に挙げた資料は参照はしますが、詳しい解説はしません。 どれも時間をかけて作成されたとてもちゃんとした資料なので、下手に説明するよりも見 た方が早いと思います。 今回は個人的にあんまりWebで見かけない以下のことについて触れたいと思います。 ● AWSのリソースという概念とモデル ● AWSサービスや機能仕様を把握する手段

AWSリソースという概念 AWSではありとあらゆるサービスモデルの実体を「リソース」と呼びます。 例えば、EC2インスタンスや、VPCネットワーク、ネットワークサブネットやIAMユーザ、 S3オブジェクト１つに至るまで全てはリソースです。 AWSリソースは、Javaなどのクラスベースのオブジェクト指向言語で例えるなら、AWS サービスクラス（モデル）のインスタンス（エンティティ）であると言えます。 リソースをクラスベースのオブジェクト指向言語におけるインスタンスと捉えると、AWS サービスの理解が早まります。

AWSリソースという概念 (ARN) JavaでいうインスタンスID、Rubyでいうobject_idに該当する、AWSリソースのIDを ARN(Amazon Resource Name)と言います。 リソースのIDであるARNは以下の形式で表されます。 arn:aws:サービス名:リージョン名:アカウントID:エンティティ名/ID もしくは arn:aws:サービス名:リージョン名:アカウントID:エンティティ名:名前

AWSリソースという概念 (ARN) 例1: EC2インスタンスの場合 arn:aws:ec2:ap-northeast-1:999999999999:instance/i-0ec08faa2c69248b0 これはシンプルでとてもわかりやすいです。 例2: IAMユーザの場合 arn:aws:iam::999999999999:user/m3-edu-user IAMのARNにはリージョン名がありません。IAMユーザはリージョンに属さないため、 ARNにリージョン名は含まれません。

AWSリソースという概念 (ARN) 例3: S3オブジェクトの場合 arn:aws:s3:::m3_edu_bucket/image/exampleobject.png S3のARNにはリージョンとアカウントIDがありませんが、リージョンやアカウントIDと関 連がないのではなく、省略されているだけです。 S3バケット名はグローバルで一意となるため、S3バケット名が特定できればリージョンと アカウントIDも特定可能です。 また、このARNの特徴として、IDに当たる部分がパス形式になっています。AWSではこ のようにパス形式となっているリソースに対してはワイルドカードで認可指定や一括取得 が可能なサービスがあります。

AWSリソースという概念 リソースはクラス（モデル）のインスタンス（エンティティ）なので、親子関係や継承関係、 コンポジションなどをクラス図で表すことができます。 ARNを見るだけでも、リソースの一意性や関連が見て取れました。 ちなみに、ARNのエンティティ名の部分が、DDD（ドメイン駆動設計）における集約 （Aggregation）のルートとなります。 S3であれば、バケットが集約のルートなので、S3オブジェクトに対する操作は（概念的 に）バケット（のエンティティ）がレシーバとなります。（実際にAWS-SDKのAPIもそういう インタフェースになっています。※） ※ 昔のSDK（Java）は全てのAPIがフラットだった

AWSリソースという概念 ARNについて解説しましたが、実際にAWSを利用していてARNを直接見る機会は実は あまりありません（IAMポリシー作成時には嫌というほど見ますが）。 CloudFormationやTerraformを利用する場合、それらツールによってRef関数の戻り値 や戻り値のプロパティなどに抽象化されています。 ただ、ARNの構成を見るだけでもそのエンティティがどのような一意性を持つのか、リ ソース間の親子関係や兄弟関係など、複数の情報を読み取れます。 このようにAWSではオブジェクト指向の概念が多く見られることが感じ取れたと思いま す。

AWSリソースのモデル 実際のリソースのモデルがどうなっているか、VPCを具体例に挙げて見てみます。ここ は重要ではないので軽く聞き流してください。 VPCは仮想プライベートネットワークのサービスです。 VPCはプロビジョニング（作成）されるまでは抽象モデルでしかありません。実際にVPC をマネジメントコンソールなどから作成することで、VPCのリソース（エンティティ）が生成 されます。 VPCは必須の属性として Region と CIDR を持ちます。その他、任意属性としてDHCP オプションなどを持ちますが、今回は割愛します。

AWSリソースのモデル VPCをクラス図で表すとこんな感じです。 VPCのCIDRのネットマスクは最大で16ビットでなければならないというド メイン制約を持ちます。 VPC VPC-ID (PK) Region CIDR 次にVPC内のサブネットをモデル化します。サブネットは必須属性として Availability Zone(AZ) と CIDR 、および親エンティティとなる VPC-ID を持ちます。サブネットのライ フサイクルはVPCに依存します。 Subnet Subnet-ID (PK) Availability Zone CIDR VPC-ID (FK) VPC VPC-ID (PK) Region CIDR

AWSリソースのモデル サブネットの属性を見れば、以下のドメイン制約が自明です。 ● サブネットの CIDR はVPCの CIDR 範囲内でなければならない。 ● サブネットの AZ は VPC の Region 内でなければならない。 また、VPCの新たな制約が判明します。 ● 各サブネットの CIDR は重複してはならない。 ○ 厳密にはRouteTableをモデル化した後に自明になります。 このように、リソースをモデル化すると自明な制約が判明します。なので、モデルを知れ ば仕様の予測がつき、サービスに対する理解が早まります。

AWSリソースのモデル ちょっと待て、リソースのモデルを知らないのに、それを知るためにモデル化するのは矛 盾していないか。

AWSリソースのモデル モデルあります。

AWSリソースのモデル リソースのモデルを把握する効果的な方法。 ● 公式のAPIリファレンス。 ○ 例: https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/APIReference/API_CreateSubnet.html ● 公式のCloudFormationのドキュメント。 ● Terraformの公式ドキュメント。 ● 公式のCLIリファレンス。 APIリファレンスやCLIリファレンスを参照する場合は `create` 系のAPIを見るとモデル がわかりやすいです。

AWSリソースまとめ ● AWSのリソースはモデルクラスのエンティティと考えると（OOプログラマは）理解し やすい。 ● モデルを把握することで機能仕様の理解速度が早まる。 ● モデルは構築系のドキュメントを見ると把握しやすい。

もう一つの機能仕様を把握する手段（限定的） AWSサービスの機能仕様を把握するうえで、最も効果的なことはモデルを知ることでは ありません。 もちろん、実際に使ってみること以上に効果的な方法はないのですが、モデルを把握す るよりは効果的な方法があります。 それは、類似プロダクトを知る（もしくは使ってみる、構築してみる）ことです。 ただ、こちらの手段はもとのプロダクトを知っていないと意味がないので、AWSを知る手 段としてはかなり限定的だと思います。

類似プロダクト一覧（例） ● EC2 KVM、Xen、Hyper-V などのハイパーバイザ ● SQS RabbitMQ、ActiveMQ などのMQミドルウェア ● VPC ルータ、iptables、firewalld などのネットワークツール ● DynamoDB MongoDB、Cassandra などのNoSQLデータベース ● EFS GlusterFS、Ceph などの分散ストレージミドルウェア ● WAF/Shield mod_security、Deep Security などのWAF ● Kinesis Apache Kafka などのストリームエンジン ● CodeBuild CircleCI、TravisCI などのCIサービス ● AppStream VMware ThinApp、XenApp ○ などなど、あまりにも多すぎて書ききれない・・・

ほぼプロダクトまんまなサービス ● Elasitcsearch Service => Elasticsearch ● RDS => Oracle, PostgreSQL など ● ElastiCache => Memcached, Redis ● OpsWorks => Chef ● ActiveDirectory => Microsoft Active Directory ● Simple AD => Samba4 ● MQ => ActiveMQ これらのサービスは、AWSのノウハウだけでなく、プロダクトのノウハウがそのまま活か せるので、情報量が多く学習コストが低くすむことが多いです。

代替プロダクトがないAWSならではのサービス ● IAM （まあこれはAWSリソースに対する認可なので当たり前） ● S3 （AWSの負債。機能単位なら類似はたくさんあるけど。） ● Elastic Beanstalk （完全に独自概念、はまりどころ多数） ● Cognito （相当複雑、いろんなプロダクトを組み合わせればいけそう） ● Certificate Manager （だって認証局になんてなれないですもの） ● AWS AppSync （「今は」まだあまりない。これから急増しそう。） ● Greenglass （これは普通真似できないでしょ） ● Connect （これぞAmazon！って感じ） ● Snowball （Amazonの真骨頂といえるサービス） これらのサービスは代替プロダクトがあまりないため、学習コストが高めです。特に利用 頻度が高い S3 や IAM に関しては、苦しんで覚えるしかありません。

AWSの情報収集 クラスメソッドブログ 正直、ここだけで基本的なことは全て完結します。 公式ドキュメント AWSのドキュメントは膨大なので、ピンポイントで調べ物するときに。 SAさんに聞く ChatworkのAWS検討窓に入れば直接質問できます。

まとめ AWSは使ってみるのが一番。 リソースのモデルを理解しよう。 類似プロダクトに置き換えてみよう。 IAMとS3はTry And Errorで苦しんで覚えましょう。

追記 AWSでセキュリティに気をつけなきゃいけないこと。 S3のバケットポリシー ● Publicだと誰でも参照可能になります。 ○ Trusted Advisorで警告表示されたりします。 EC2やElasticBeanstalk、ECS上に構築したアプリケーション ● アプリケーションの脆弱性対策はユーザの責任範囲です。 内部犯行対策（次のスライドに続く）

追記 内部犯行に対する対策もユーザの責任範囲です。 IAMユーザによる適切な認可管理を行う必要があります。 EC2にログインするための秘密鍵の管理もユーザの責任です。

追記 リージョンの選定基準 レイテンシ以外に、リージョンによって利用可能なサービスが異なるのでそこも考慮する 必要があります。 例えば、メールサービスのSESはUSとEUのリージョンでしか利用できません。 新しいサービスも、東京リージョンはだいたい初期から使えますが、ものによってはUS よりも半年くらい遅れることがあります。Firehoseなんかは１年以上遅れました。 他にも、法律の問題があります。

追記 用語 SA => ソリューションアーキテクト AWSコンサルみたいな人。AWSJという会社の人。 DR => ディザスタ・リカバリ 災害に備えて遠隔地に同じシステムを構築しておくこと。 大阪リージョンができたのでDRしやすくなった。