AWS Cloud Practionerへの道 #2 サービスロケーションとプロビジョニング


## サービスロケーション周りの話

### Regions

高い可用性を保つためには、そのための設備が必要。一つのデータセンターにすべてが集約されていると、そのデータセンターが何かしらの問題で利用不可になると影響がとても大きくなる。また、そういったケースを想定してディザスターリカバリープランを顧客に説明する必要があったりする。

AWSはグローバルレベルで複数の独立したデータセンターを持ち、必要に応じて複数のデータセンターにまたがるシステム設計をすることでサービスを展開し続けることができる。独立しているので、データセンター間のセキュリティは保たれながら、明示的にデータセンター間のデータをやり取りすることもできる柔軟性がある。

これらのオプションを持つことは、

- コンプライアンス、法やポリシーを守るのにも役立つ
- サービス提供地に近いデータセンターを使うことでレイテンシを最小化できる
- 一部の地でしか提供できないサービスを遠隔から利用できる
- 金額的なメリット、提供する場所の税制や物価などに応じてベストな選択肢を選べる

### Availability Zones

Availability Zoneとは直訳で利用可能なエリアとなるが、これはリージョン内の1つ以上のデータセンターの単位を指す。Availability Zonesはお互い距離をとって配置されており、このことはディザスタープルーフ（耐災害性）にも寄与している。たとえば地震や台風などの自然災害で１つのAvailability Zoneがダウンしても異なるAvailability Zoneで事業が継続できる、というようなイメージ。

そういった観点からAWSとしては1つのRegion内の複数のAvailability Zonesにまたがって冗長構成をとった運用を推奨している。これはビジネスの性質に合わせて選択すればいいのかなとも思う。

複数のAvailability Zonesにまたがろうと、同一Region内であれば連携がスムーズにできるよう多くのサービスはRegional Constructで作られている。たとえばELBはRegional constructであり、同じRegionのEC2と特に何もしなくても連携されるようになっている。

- Regionの中に複数のAvailability Zonesがある
- 可用性を高めるため複数のAvailability Zonesをまたがって動くようRegional Constructされてるサービスが多い

### Amazon Cloudfront & Edge Locations

ユーザーが世界中にいる場合はリージョンはどう選べば良いのか。一つの方法はContents Delivery Network(CDN)を使い、オリジナルのデータのキャッシュをユーザーの近いロケーションで提供する方法。AWSにおいてはAmazon Cloudfrontという名前でサービスを提供している。

:::note warn
そういえばサービス名の接頭辞としてAmazonを使うパターンとAWSを使うパターンがあるのはなんでだろと思って調べると同じ疑問のStackoverflowがありました。

[Why some services are called "AWS XXX" and the others "Amazon XXX"](https://stackoverflow.com/questions/33125790/why-some-services-are-called-aws-xxx-and-the-others-amazon-xxx)

他のサービスと組み合わせるユーティリティサービスにはAWS、スタンドアロンサービスには「Amazon」が頭につくパターンが多いそうですが、すべてがそういうわけでもないみたい。覚えづらい。AWSの中の人は間違えないで言えるのだろうか。
:::

Cloudfrontは画像や動画やアプリケーションを低いレイテンシーで提供するためにEdge locationsを利用する。Edge locationsはRegionsと切り離されていて、別Regionにコンテンツを移動させなくても提供できる仕組み。ユーザーはEdge locationにアクセスし、そこにあるキャッシュにアクセスする。Amazon Route53などのDNSと連携することもできる。

### AWS Outposts

すべてがクラウドで実行できるとはいいつつ、法令上だったり、過去の資産だったりでオンプレミスのサーバーはまだまだ現役だったりする。それらと連携を図るように、AWSのインフラやサービスをオンプレのデータセンターにまで拡張するのにAWS Outpostsというサービスが提供されている。

> AWS のインフラストラクチャとサービスをオンプレミスで実行し、真に一貫したハイブリッドエクスペリエンスを実現

物理的にラックをAWSから貸与され、それを自社のデータセンターで使うことが出来るサービス。データレイテンシーを極限まで下げたいケースやディザスタープルーフのために使う。

## AWSリソースのプロビジョニング

すべてのAWSサービスはAPIで連携する。APIの手続きに則って呼び出すことで、プロビジョニングや設定や管理など色々できる。

- AWS Management Console
- AWS CLI
- AWS SDK
- その他ツール

### AWS Management Console

ブラウザからアクセスできるコンソール画面。コンソール画面といってもWebベースのGUIなので操作はしやすく、最初にサービスを理解するために使うのオススメ。

### AWS CLI

ターミナルからAWSリソースのAPIを実行できるので、スクリプト化し、くり返し使うことができる。これは、Management Consoleだとポチポチしなくてはいけないので、自動化という視点でも有効。

### AWS SDK

自分たちのプログラムからSDKを利用してAWSリソースのAPIを実行できる。自分たちのダッシュボードとか作れそうですね。

### AWS Elastic Beanstalk

EC2ベースのプロビジョニングツール。アプリケーションのコードと、コンフィギュレーションを与えることで全体の設定をしてくれる。インフラを気にする割合が減る形。以下のタスクを実行してくれる：

- キャパシティの調整
- ロードバランシング
- 自動スケール
- アプリケーションのヘルスモニタリング

### AWS CloudFormation

CloudFormationと呼ばれるYAMLなどのテンプレートファイルを元にEC2やstorage, machine learningなどさまざまなリソースをまとめて並行的にプロビジョニングしてもらえます。いわゆるIaCなので、Gitでのバージョン管理やリピータブルな環境構築に使えそうです。ミスも減ります。

:::note warn
じゃぁCloudFormationとElastic Beastalkの違いは何なのか、と疑問になって調べると、Elastic Beanstalkの内部でCloudFormationが動いているらしい。

[AWS CloudFormation のよくある質問
](https://aws.amazon.com/jp/cloudformation/faqs/#:~:text=AWS%20Elastic%20Beanstalk%20%E3%81%AF%E3%80%81%E3%82%AF%E3%83%A9%E3%82%A6%E3%83%89,%E3%82%B5%E3%82%A4%E3%82%AF%E3%83%AB%E3%82%92%E7%AE%A1%E7%90%86%E3%81%A7%E3%81%8D%E3%81%BE%E3%81%99%E3%80%82)

Beanstalkがサポートする範囲ならElastic Beanstalkが楽そうですし、それを超えるのであればCloudFormationでプロビジョニングするのが良さそうですね。Elasticって言葉、AWSめっちゃ気に入ってますね。サービスの性質を表現している良い言葉なのでしょう。
:::

## まとめ

- AWSはサービスの性能や可用性を高めるためにRegionsやAvailability Zoneをグローバルに提供
- グローバルなサービスについてはCloudfrontを使ってEdge locationでCDNの形で提供
- AWSのリソースをプロビジョニングする方法は色々ある
    - AWS Management Consoleから始めて、慣れたり繰り返しがあればIaC系の手順に移行しよう