Amazon Web Servicesとは、日本や世界の企業を陰で支配する、Amazonの謎のウェブサービスである。
概要
Amazonといえば、一般的には通販サービスのイメージが強い。 しかし営業利益を見ると、AWSが通販と同等、あるいはそれ以上の利益を叩きだしている。 [1]
Amazonにとって、AWSは主要な稼ぎ頭なのだ。
それなのにAWSが一般に知られていないのは、主に以下のような理由がある。
しかし、AWSは巷のレンタルサーバ屋などとは一線を画す存在なのだ。そこでここでは、まず利用ケースとしてウェブサービスを始める場合を例として挙げ、それをもとにAWSの機能を説明する。
事前知識
まず、こんなケースを想定してみよう。
- あなたは、ITとは無関係の中小企業に勤める会社員である。ある日、上司にこんなことを言われた。
「あーキミ。今度、ウチで独自にブラウザゲームを作って配信したいと思うんだが。プロジェクトの担当、ゼロからよろしく」
……もうやだこの会社。
おそらくこのプロジェクトの問題は数えきれないほどあるだろう。しかし一番の問題は、この会社にウェブサービスを提供する土台がないことである。そこで、ブラウザゲームのような、我々一般ユーザー使うウェブサービスを提供するには、あらかじめどんな準備が必要なのか考えてみよう。
ウェブサービスを提供するために
- まずはなによりサーバがなければ始まらない。なじみがないかも知れないが、サーバルームと呼ばれる部屋で、本棚のようなでかいラックでマシンが動いている画像を見たことがあるだろう。え、サーバルームやラックを置くスペースが会社にない? 会社の工事から始めましょう。
- サーバと一言で言っても、その目的によって名称が分けられる。ウェブページを表示するためのウェブサーバ、ゲームの処理そのものを担当するアプリケーションサーバ、ユーザー名やゲームスコアなどデータベース情報を保存するデータベースサーバなどを用意する必要があるだろう。
- しかしこれらのサーバを1台だけ用意したのでは、どこかが壊れた時点でサービスが止まってしまう。冗長構成、つまり各サーバのスペアを用意しておき、故障したら切り替える必要があるだろう。これを人手に任せると時間がかかりすぎるため、スペアとのデータをあらかじめ同期しておき、故障があったらこれを検知して自動的に切り替える仕組みも必要になる。これにももちろん、それ用のサーバが必要になる。
- マシンの負荷を下げておき、処理があふれない対策も必要だ。これもやはりサーバを複数用意し、同じ処理でも今の処理はこちら次の処理はあちらと担当を振り分けることで対処する。これをロードバランシングと呼ぶ。これはSNSでバズったり、DDos攻撃を受けたりした場合のバースト対応にもなる。サーバを一通り用意したらネットワークを構成しよう。コンテンツ、ここではゲーム本体を作成するのと並行し、あらかじめドメインを取得し覚えやすいURLを作っておくとよい。
- もしサービスが無事にスタートしたら、各機能が無事に動いていることを監視する仕組みも欲しい。メモリやCPU、データ量などをチェックし、異常があったらメールで通知する、なんなら自動で修正する、という具合である。また、他のユーザーの個人データを覗けたら大変だ。アクセス制御も必須である。
ここで挙げたものはサービスを開始・運用するために必要な要素のごく一部だが、実に複数の要素が絡んでいるのが分かるだろう。
さらに加えて言えば、これら要素のほぼ全てで専用のソフトウェアを導入する必要があったり、マシン自体を設定したりと何かと複雑な手順が必要である。すると、そのための手順書の作成や再設定の手間も無視できないものになってしまう。
AWSは何ができるのか
上記の例で挙げたような面倒な諸々を、すべてブラウザ上の画面操作から済ませることができる。CUI(aws cli)を使えばコマンド操作も可能である。
例えば、画面上からサーバのスペックを指定すれば、Amazonがどこかのデータセンターで保有するマシン(仮想マシン)が払い出され、リモートで利用可能になる。一方、目的に応じたサーバやソフトの設定をすでに終え、その機能だけを画面から利用可能にしたサービスをAWSでは100以上も用意しており、実際に利用する場合はむしろこちらがメインになる。また、上記の例ではウェブサービスの例を挙げたが、コーディングなど開発に関する機能や、AI(機械学習)など流行りの機能もAWSは揃えている。
AWSの強みはこれらサービスの豊富さと手軽さである。上手に組み合わせることで、管理しやすい、更新が楽、アクセスが早いといった特徴を持つ「サービス作りの土台」を手軽に組み立てることができる。後述するAWS Lambdaなどを使うことで、サーバを使わずサービスを提供することも可能である。
一方、各サービスを組み合わせるのがメインの利用法になるため、一度AWSを使ったら、その後もずるずるとAWSを使い続ける……という事態に陥りやすい。もうAWSのない開発は考えられない、というIT企業は少なくない(はず)。
AWSの主なサービス
AWSには100以上ものサービスがあると前述したが、ここではその中で主要な物を紹介する。
EC2
比較的イメージしやすい「レンタルサーバ」に一番近いのがコレ。CPU、メモリ、ディスク容量などを指定するとそのマシンがリモートで利用可能になる。マシンを作ったり消したりコピーしたりが気軽にできる。また料金は高額になる(例えば2021年9月時点において、東京リージョンでp2.xlargeインスタンス(4CPU・61GBメモリ・GPUメモリ12GB)のインスタンスは1.542ドル/時だが、r5.2xlarge(8CPU・64GBメモリ)は0.608ドル/時。ディスク代はどちらにも含まれない)ものの、AI開発にほぼ必須のGPU付きマシンも使える。
なお、多くのレンタルサーバとは異なり、時間単位で借りられるので(60秒以上1秒単位)、本当に必要な時だけ借りる運用も可能。
ELB
ロードバランサ。EC2と一緒に使うのが基本で、実際Web上の起動はEC2のサービスコンソールから行う。
ECR
Dockerコンテナのレジストリ。後述するECSと併用するのが基本。
ECS
Dockerコンテナをオーケストレーションする仕組み。KubernetesベースのEKSというのもある。コンテナ基盤としてFargateを用いると、下にあるインスタンスのことは一切気にしなくて良くなる。
CloudWatch
監視サービスがメイン。これにより高負荷になったらイベントを発生させるなどの処理が可能。
Auto Scaling
自動でインスタンスの数を増減させるEC2 Auto Scalingと、DynamoDBのキャパシティなどを増減させるApplication Auto Scalingの2種類がある。
S3
ストレージサービス。GoogleドライブやDropboxがちょっとリッチになった感じと言えばだいたいあってる。
RDS
データベース。MySQLやPostgreSQLなど有名なデータベースはだいたい利用可能。
DynamoDB
上記と同じようにデータベースなのだが、SQLベースではなく、Partition KeyとSort Keyを用いて検索する。
Route 53
DNSサービス。ドメイン管理自体をAWSに任せても良いし、ドメインは他で管理してDNSサーバだけをAWSで借りてもよい。
Lambda
サーバを使う、すなわち「CPUやメモリなど、リソースを確保したうえで何か処理をする」のではなく、「リクエストやアクションなど、処理そのもの」を指定し、それに対し課金するサービス。サーバの設定にうんざりしなくて済む、リソースの見積もりや不足から開放されるなどのメリットがあり、最近流行している。
CloudFront
CDNサービス。S3と併用すると、サーバを借りることなく静的なWebページを構築することが可能。
API Gateway
API提供サービス。裏にLambdaを繋げることで、APIシステムを簡単に構築可能。
CodeGuru
先述の場合、どのようになるのか
- まず、Amazon Web Servicesと契約する
- 次に、Amazon Virtual Private Cloud(VPC)の機能を使ってVPCを作成し、そこにサブネットを構築し、適切なルーティングテーブルを設定することでネットワークを構成する
- Amazon Route 53を使ってドメインを取得し、管理する
- データベースサーバとしてAmazon Relational Database Service(RDS)を用いてRDBサーバを構築する。また、キャッシュサーバを使いたいならAmazon ElatiCacheを利用可能。単純なKey-Value検索しかしないのであればデータベースサーバとしてAmazon DynamoDBを使うのもありだろう
- アプリケーションサーバやウェブサーバには、サーバベースであればAmazon EC2が、DockerコンテナベースであればAmazon ECSやAmazon EKSが利用可能。関数ベースのシンプルなシステムであればAWS Lambdaでロジックを実装し、Amazon API GatewayでAPIを提供するのもありだろう。その場合、フロントの静的なコンテンツはAmazon S3に配置し、それを配信するためにAmazon CloudFrontを使うことになる(そして、Amazon API GatewayのAPIもAmazon CloudFront経由で配信可能)
- ロードバランシングにはElastic Load Balancing(ELB)が利用可能。また、バースト対応が必要であるならば、EC2インスタンスベースであればAmazon EC2 Auto Scaling、コンテナベースであればApplication Auto Scalingを用いて処理できるサーバ数を増やすことで対応可能。サーバレスベースにする場合、ロードバランシングは勝手に行われるし、バースト対応も勝手に行われる
- 監視する仕組みとして、Amazon CloudWatchというサービスを用いることで、インスタンス等の負荷監視、ログ確認等が可能。アクセス制御にはAWS IAMというサービスが利用できる(ただし、AWSリソースへのアクセスに限られる。アプリケーションデータのアクセス制御は、アプリケーションの仕事なので、基本的にアプリケーションが責任をもって行う)
その他
- これまでさんざんAWSは企業が使うものだと書いたが、クレジットカードさえあれば別に個人でも使える。費用は他の類似したサービスに比べ割高な印象だが、その豊富なサービスやリソースを一度使ってみるのもいいだろう。
- 大抵のものは実体を契約者が借りる必要はないが、Snowファミリー(テラバイトやエクサバイト単位のデータを物理的にAWSに転送するサービス)やOutposts(オンプレミスでAWSと同等のインフラストラクチャをAWSと連携して実行するサービス)などは、契約者がAWSから物理的な資材を借りる。
- AWSのサーバやサービスが稼働しているデータセンターは、凄腕のスパイやハッカーでも分からない場所に厳重に秘匿され、テロや大災害にも耐えられるように世界各地に分散している。いやマジで。
関連動画
バカでかいAmazon EC2インスタンスでUnrealEngineをビルドしている動画をどうぞ。動画についている「Spot Instance使えば1時間5ドルくらいですね」というコメントが、そのバカでかさを物語っている(Spot Instanceというのは、いつ終了するかわからないが、入札した額より料金が上がらない限り、スポット料金で利用可能なインスタンス。オハイオリージョンで、Windowsインスタンスを1時間借りた場合、3.9961ドルの費用がかかる(2022年8月28日11時51分現在)が、オンデマンドインスタンスだと6.372ドルである)。
こんなバカでかいサーバを時間単位で借りられるのも、Amazon Web Servicesの強みでもある。
関連項目
- AWS
- Google Cloud Platform(GCP)
Googleによる同様のウェブサービス - Microsoft Azure
Microsoftによる同様のウェブサービス - Amazon
- サーバ
- データセンター
脚注
- 14
- 0pt