https://medium.com/aws-activate-startup-blog/scaling-on-aws-part-1-a-primer-dbf1276ded5a の個人的な翻訳というかメモです。所属する企業や団体における公式見解ならびに公式発表ではございません。
スケールするオンプレミスのインフラストラクチャの実現は難しいと思います。ピークのキャパシティを見積もり、機器の到着を待ち、ハードウエアとソフトウエアのセットアップをし、全てが正しく稼働をすることを願う、、。
恐らくCloudにデプロイを行うことで、それらの頭の痛いことを解決できると聞いたことがあるでしょう。ということで、あなたのボスもしくはあなたはイロイロ物色した結果、AWSを試してみることになりました。
AWSのインフラストラクチャをプロパーにスケールさせるお仕事のはじまりです。まず来るべきScaling on AWSする上でのベストプラクティスや一般的なガイドラインがないか？と思うことでしょう。このブログシリーズは、まさにそこを目的としています。Scaling on AWSはトラディショナルなインフラストラクチャと比較して、もし、適切なAWSサービスを知っていて、必要に応じてプロビジョニングすることが出来れば、実際にシンプルです。
私はこれからアプリケーション開発社としてスケーリング事例をウォークスルーしていきます。なぜ確かなAWSアーキテクチャに導入するかだけでなく、意思決定におけるモチベーションも併せて紹介します。
それでは冒険をはじめましょう！
AWS Background Knowledge
スケーリング事例に行く前に、どのようにAWSのグローバルインフラストラクチャが非常にスケーラブルなワークロードをサポートするようにデザインされているか見てみましょう。
Regions
AWSインフラストラクチャのハイレベルビューからはじめましょう。最初に注目すべきはregion(リージョン)です。リージョンはデータセンターのクラスタが存在する物理・地理的なロケーションです。
現在、AWSには11のリージョンがあり、これから5つ追加予定です:(Korea, India, Ohio, UK, そして中国の2つ目のリージョン)
お客さまはいくつかの基準をもってリージョンを選択します。
- エンドユーザーから距離が近いこと
- 情報規制の条件
- 今後の拡張戦略
- コスト
- サービスの可用性
それに加えて、AWSはアプリケーションおよびデータをリージョンを越えて簡単にマイグレーションすることを可能にしています。実用的な課金モデル、ツール、サービスはリージョンを越えたマイグレーションを手助けし、リロケートや既存のAWSインフラストラクチャを後からright-sizeにする際の沢山の選択肢をもたらします。
一般的には、ネットワークのレイテンシを抑えるためにエンドユーザーから最も近いリージョンにデプロイすることが望ましいです。私のアプリケーションにおいては、ポテンシャルユーザーは北アメリカに広がっているという仮説を立てました。AWSは北アメリカにN.Virginia, N. California, そしてOregonという3つのリージョンを持っています。私はOregonにデプロイすることにしました。理由は少しコストが安く、私が住んでいるところから近いからです。
Availability Zones
リージョンの中には2つもしくはそれ以上のAvailability Zoneが存在します。Availability ZoneはよくAZと略されます。AZは独立したデータセンターのクラスタで、他のAZの障害の影響を受けないようにデザインされています。AZは独立した異なる電力系統を使い、断層線や氾濫原が異なるところに配置されています。同一リージョン内であれば他のAZに対してsingle digit millisecondで通信することが可能です。
AWSを使い始めた時点では、高い可用性はそこまでクリティカルでないかもしれませんが、徐々に複数のAZにデプロイを行いたくなるでしょう。そうすることで、様々な(レアなロケーション停止を含む)タイプの障害に耐えることが出来るようになります。
現時点で覚えておいていただきたいのは、AWSインフラストラクチャは高い可用性をほこるアーキテクチャであるということです。このトピックに関しては後から別のブログポストでも扱います。
Overview of the AWS Platform
2006年から、AWSは成長を続け、豊富なサービスを持ち、ビルディングブロックのように、スケーラブルで、コストエフェクティブで、そしてセキュアなインフラストラクチャを、お客さまが構築するお手伝いをしてきました。
下記のダイアグラムはAWSのサービスの幅広いカテゴリを示しています。
リージョンおよびアベイラビリティゾーンを含むグローバルインフラストラクチャに関してディスカッションしてきましたが、このグローバルなフットプリントが、あなたのお客さまのそばにデプロイをすることを可能にし、必要なワークロードへの移行も可能にします。
グローバルインフラストラクチャ上に、AWSはcompute, storage, networking, そしてsecurity and administrationというサービスを持っています。
これらのコアカテゴリに属するサービスを使って、仮想マシンのアナロジーであるEC2(Amazon EC2)インスタンスをローンチすることができ、AWSのリソースをセキュアにモニタリングし(AWS Identity Access Management もしくは IAM, そしてAmazon CloudWatch)、お客さま独自のネットワークのトポロジを決める(Amazon VPC)ことができます。これらのサービスはAWSクラウドの中に仮想データセンタを構築することを可能にします。
データサービスカテゴリでは、AWSは、Amazon Relational Database Service(RDS)やAmazon DynamoDBといった、マネージドなリレーショナルそしてノンリレーショナル・データベースサービスを提供しています。
マネージド・サービス活用することでバックアップやソフトウエアメンテナンスまたはフェールオーバー管理といった管理業務を自身で行う必要がなくなります。
またAmazon Redshiftはマネージドなデータウエアハウスサービスですが、カラムナー型のストレージに非常に効率良くデータを保存することが出来、テラバイト級のデータを1年間で1000USドル以下に抑えることが可能です。
もしビッグデータを処理および解析する必要があれば、AWSが提供おするAmazon Elastic MapReduce(EMR)を使うことが出来ますし、Amazon Kinesisを使えばリアルタイムにデータを解析することが可能で、Amazon Machine Learningを使えば、簡単に機械学習技術を簡単に導入することができます。これらのテクノロジーの詳細は後のポストでDeep Diveします。
更に、AWSはいくつものアプリケーションサービスを保持しています。これらのソフトウエアコンポーネントは、従来は自社開発もしくはアウトソーシングされていて、ビジネスに対する差別化をもたらすことはありませんでした。
AWSでは、一般的なコンポーネントをplug-and-play形式で取り込み、使った分だけ料金を支払うことで、時間とお金を節約することを可能にします。ここでいう一般的なコンポーネントとは、データベースサービス、データウエアハウスサービス、キャッシュサービス、キューイングサービス、通知サービス、メールサービス、その他沢山のものを含みます。
AWSプラットフォームは50以上のサービスを使ってお客さまがクイックにコスト効率よくインフラストラクチャを構築することをエンパワーメントします。
Day One, User One
今、あなたはAWSが広大なインフラストラクチャ保持し、スケーラブルなアプリケーションを構築するための様々なサービスを提供していることを知りました。どこからはじめましょう？もし、ちょっとためしたいだけであれば、一つの箱の中にシンプルなアプリケーションを構築することができます。
例えば、あなたがLAMPスタックのディベロッパーもしくは、.NETディベロッパーであり、Webサーバー/アプリケーション・サーバー/データベースを単一のEC2インスタンスにホストすると決めたとします。
AWSはとても簡単に仮想マシンを構築できるように、よくあるテクノロジースタックをAmazon Machine Images(AMI)という方法で提供します。AMIは仮想マシンのスナップショットのアナロジーです。AWS Management ConsoleもしくはAWS CLIを使って仮想マシンを起動する際に、LinuxやWindowsベースのサーバーの特定のAMIを選択することができます。
次に、セキュアな仮想ネットワーク、例えばVPCの中のpublic subnetにEC2インスタンスを立てたくなるとします。
大丈夫です、説明なしに沢山の専門用語を使っていることを理解しています。先にすすむ前にそれらの意味をみていきましょう。
Amazon Elastic Compute Cloud (Amazon EC2)
- EC2インスタンスは仮想マシンと同等のものです。インスタンスはグループに分けられ、あなたのユニークなワークロードのニーズに対応するため、それぞれ異なるCompute, Storage, そしてnetworkリソースが割り当てられています。一般的にGeneral purpose instance familyというバランスのとれたリソースが割り当てられたインスタンスを使ってスタートするのが良いと言われています。ワークロードリソースのニーズは、モニタリングを通して、より良いパフォーマンスやコスト効率追求への機会を導き出すことができます。私の最初のアーキテクチャはVPC内のpublic subnetの中にt2.mediumを起動する、というものです。
Amazon Virtual Private Cloud (Amazon VPC)
- Amazon VPCは、論理的に隔離されたAWSクラウド上にあるセクションで、あなたが定義した仮想ネットワーク内にAWSリソースをローンチすることができます。IPアドレスレンジ、サブネット、そしてルーティングルールを完全にコントロールすることができます。
VPC subnet
- サブネットはAvailability ZoneのVPC内のIPアドレスレンジの一切れです。public subnetにデプロイされた仮想マシンはpublic IPアドレスがランダムにアサインされ、他のインターネットホストからvisibleになります。サブネットをpublicにするにはルーティングルールを作成し、 インターネットバウンドなトラフィックをインターネットゲートウェイに向かうようにします。水平にスケールし、冗長化され、高い可用性をもつVPCコンポーネントはVPC内のインスタンスとthe Internetのコミュニケーションを可能にします。
Amazon Route53
- Route 53は高い可用性をもつ、スケーラブルなクラウドDomain Name System(DNS)サービスです。開発者およびビジネスに対して極めて信頼性が高くコスト効率の良い方法でユーザーとインターネットアプリケーションのルーティング(例: www.example.com を 192.0.2.1 といったIPアドレスに変換し、接続できるようにする)が行われるようにデザインされています。
Day Two, User > 1
上記で構築したオリジナルアーキテクチャはトラフィックが増大するまでは問題ありませんが、次はスケールについて考えていきます。クイックなソリューションとしては、より大きな箱にして垂直にスケールさせることです。EC2には244GBのRAMもしくは40仮想コアを持つようなインスタンスもあります。パワフルなインスタンスにアップグレードするのはとても簡単です。例えば、Amazon Elastic Block Store(Amazon EBS)をroot volumeとして使えば、EC2インスタンスを止めて、インスタンスタイプを変えて、インスタンスを再スタートされるだけです。この間にかかる時間は数分です。
AWS EC2は現状40 vCPUそして244 GBメモリのインスタンスを提供しますが、垂直スケールは時にして頭打ちになります。それに加えて、他にもこのアーキテクチャには問題点があります。第一に、1台しかインスタンスが無いということは、冗長性がないということです。第二に、1つのAZにのみ存在するということはアプリケーションの状態は単一のロケーションと運命を共にするということです。
垂直スケーリングの問題点を解決するため、アプリケーション層を分離することをオススメします。アプリケーション層におけるリソースのニーズは他とは異なる勢いで成長しがちです。層を分けることで、それぞれの層に対してリソースのニーズに応じた相応しいインスタンスタイプでの構成を組むことができます。全てが一つのEC2インスタンスに入っていたオリジナルのアーキテクチャから、層を分けることに取り組むと、下記のダイアグラムのような構成になります。
次に、アプリケーションを分散できるようにデザインしてみましょう。例えば、どのWebサーバーにリクエストが振り分けられたとしても同じユーザーエクスペリエンスを提供する必要があります。つまりアプリケーションの状態を独立させることでその後に続くリクエストは同じサーバーで処理する必要はなくなります。一度サーバーがステートレスになると、その層にインスタンスを追加することでスケールさせることができます。リクエストをそれぞれのEC2にロードバランスするためにElastic Load Balancing(ELB)を利用します。
ELBはロードバランシング用のサービスでアプリケーションにやってくるリクエストを分散させます。ELBは水平にスケールし、帯域のリミットはなく、SSLターミネーションをサポートし、healthyなインスタンスのみがトラフィックを受け取るようにヘルスチェックを行います。ELBロードバランサーはインターネットに対してpublic facingな用途でも、closed offな用途にも利用することが出来ます。
下記のアーキテクチャは水平にスケールします。コスト効率がよくハイボリュームのトラフィックをハンドリングすることが可能です。エキゾチックでハイパフォーマンスをほこり、そして高価なサーバーを使うよりも、コストの安いコモディティなサーバーを活用してリクエストを捌くことができるのです。
次のポストでは、アーキテクチャの切り離しを更に進め、増えていくトラフィックを捌けるように進化させていきます。データベースのオプションや更に多くのAWSサービスにも言及していきます。
#Summary
- AWSのグローバルインフラストラクチャや、ネットワーク、コンピュート、特にAmazon VPCとAmazonEC2といったコアとなるサービスを理解した上でget started on AWSできるようになりました。
- 垂直スケーリングは一つのスケーリング戦略ではありますが制限があります。ハイトラフィックをコストエフェクティブに捌くために水平スケーリングを選択することが出来るようになりました。
- 水平スケーリングにおいて、アプリケーションは分散するアーキテクチャを持つ必要があり、 アプリケーション層は分離されている必要があります。このやり方によりオーバープロビジョニングを避けることができ、異なるEC2インスタンスタイプを最大限に活用することができるようになります。