目次
はじめに
データイノベーション部浅田です。
人気漫画「鬼滅の刃」に仮託して、「雲(クラウド)の呼吸」と題しまして、AWS(Amazon Web Services)を用いたアーキテクチャ設計の勘所を数回にわけて書いていきたいと思います。
なお、AWSに関するサービス名に関しては、この記事内で初出時は正式名称をつけ、以降は明確な場合は省略系を用いる方針で記述しています。
第二回目は「マネージドサービス・前編」です。
マネージドサービスの利用
「方法は見つける。なければ作る。(Aut viam inveniam aut faciam)」
古代ローマと戦ったカルタゴの名将ハンニバル・バルカは、当時不可能と言われていたアルプス越えを行って、ローマの度肝を抜きました。上記の言葉は、その際に部下から「アルプス越えが不可能である」と諌められた際に発した言葉とされています。
さすがはハンニバル、他の人間にはできないことをやってのける。そこに痺れますし憧れますが、彼の言葉の裏返しとして「方法がすでに存在するならば、それを利用すればよい」ということでもあります。事実、ハンニバルは地元の人がアルプスを越えている道があることを調査した上で、アルプス越えに挑んでいます。
AWSに限らず、クラウドとオンプレミスとの違いの一つとして数々のマネージドサービスがあげられると思います。実際、AWSが最初に産声をあげたとき(2004年)、提供されたサービスはAmazon Simple Queue Service(SQS)でした。SQSに限らず、現在にいたるまで色々なマネージドサービスが提供されています。AWSを用いてよい設計を行うということは、それらのマネージドサービスをいかにうまくつかうかということでもあります。
なぜマネージドサービスを積極的に利用すべきなのか
マネージドサービスを利用しない場合、同等の機能を自前で構築していくことになります。たとえば、SQSであれば自前でキューイングのシステムを構築するということになります。
確かに自前で構築を行えば、高度の柔軟性を維持しつつ臨機応変に対処することができるかもしれません。ですが、AにはAに向いた話、BにはBにふさわしい任務というものがあるはずで、マネージドサービスと同等に作り込めるような技能が必ずしもあるとは限りません。仮にあったとしても、相応の時間をかける必要があります。
しかも、必要な技能を身につけ、必要な時間をかけて構築したとしても、マネージドサービスより優れている点がなければ、マネージドサービスを利用しているユーザと同じ土俵にやっと立てた、ということにしかなりません。
マネージドサービスを利用することで、人的、あるいは時間的コストを削減し、競争優位を生み出す作業にリソースを集中することができるということが、マネージドサービスを利用する最大のメリットであり、クラウドを使うメリットでもあると言えるでしょう。もちろん、その方が楽でいい、ということもあるでしょう。
そして、多くの場合、コストも安く済む
AWSのマネージドサービスを利用することは、多くの場合コストを抑えることにも繋がってきます。それは、多くのマネージドサービスがサーバレスで提供されているからでもあります。第一回目のコスト編で述べたように、サーバレスの利用はコスト削減を図れる可能性が高くなります。
Amazon RDSや、Amazon ElastiCacheのように、起動時間で課金されるようなタイプのものは、Amazon EC2で作り込んだよりも運用費用が高く見えるマネージドサービスもありますが、冗長性を担保し、障害時に自動でフェイルオーバを行うように構築する手間や時間にかけるコストと費用とを天秤にかければ、結果的には安くなるケースが多いでしょう。
代表的なマネージドサービスとその用途
さて、前置きが長くなりましたが、AWSの設計を行う上で、代表的なマネージドサービスとその用途について、概観していこうと思います。
Elastic Load Balancing
ロードバランシングをおこなってくれるサービスです。デフォルトで冗長化されていますし、負荷に応じて自動でスケーリングしてくれます。
その名の通りアプリケーションの負荷を分散し、サービスの障害性を高めるというロードバランサー本来の機能に加えて、以下のようなメリットもあります。
- AWS Certificate Managerとの連携によりSSL終端処理を行うことで、HTTPSでのサービス提供を容易にする
- 無料でSSL証明書を取得できる
- HTTP/2に対応しているので、サーバ側で何もしなくてもHTTP/2のメリットを享受できる。
- HTTP to HTTPSなどのリダイレクトもリスナールールで提供できる(ALB)。
- パスベース(L7)でのルーティングに対応(ALB)
- 固定IPでのロードバランシングを提供(NLB)
- AWS WAF & Shieldによるセキュリティ対策
- AWS Lambdaの実行
- スティッキーセッションによるセッション維持
なども利用できます。
冗長性を担保することをベストプラクティスとするAWS設計において、EC2を使用する環境においては、マストなサービスといえるでしょう。
ただし、スケーリングに関しては、スパイクアクセスに対応できない場合があるので、事前の暖気申請を行うなど対応が必要なケースもあるのは注意が必要です(NLB以外)。
Amazon S3
AWSにおけるストレージソリューションの第一候補にあがるといっても過言ではないS3は、代表的なマネージドサービスといっていいでしょう。
S3のマネージドサービスの利点としては、
- 無制限の保存容量
- 耐障害性（複数の箇所にデータをレプリケーション）
- データのバックアップとしてのレプリケーション
- 同じリージョンへのレプリケーションや海外リージョンへのクロスリージョンレプリケーションも設定可能
- バージョニングによるデータの保護
- ライフサイクルポリシーによるオブジェクトの自動削除
- バケットポリシーによるクロスアカウントの利用
などを簡単に利用できてしまいます。
また、データレイクとして、数々のAWSサービスと連携する起点になっています。
Amazon RDS & Amazon ElastiCache
RDSやElastiCacheはよく使われるマネージドサービスでしょう。
RDSはMySQL、MariaDB、PostgreSQL、SQLServer、OracleといったRDBMSのマネージドサービスであり、RDBMSを利用するケース非常に多いでしょう。
ElastiCacheはRedisや、MemcachedのNoSQLのマネージドサービスになります。セッション情報や、キャッシュなど、レイテンシの低さを利用した用途や、あらかじめ構造化できないデータを保存するなどのように向いているので、これもよく使われるかと思います。
これらのマネージドサービスを使うと、
- 可用性を考慮したMultiAZの構成および、フェイルオーバ
- 定期的なバックアップによるデータ保全
- 暗号化によるデータ保護
- リードレプリカ 追加による読み取り能力のスケーリング
などをオプション一つで実現できます。
Amazon SQS
SQSはメッセージキューイングサービスのマネージドサービスになります。メッセージキューを使うことで、システムを疎結合にすることができます。
例えば、あるシステムAからシステムBに処理を依頼するときに、直接AからBのAPIを実行してしまうと、BはAがどれぐらいAPI実行を依頼してくるかを想定して、リソースを確保したり、処理途中で失敗した場合などにエラーハンドリングをどうするかをA側も気にしなくてはいけなくなります。
ですが、間にキューを挟むことによって、B側のリソースの都合に応じて依頼（キュー）を処理することができるようになります。エラー時も再度キューを処理しなおすなどB側だけでコントロールが効くようになります。A側もキューに入れることだけを考えればいいので、Bのリソースや実装に依存しなくて済むようになります。
このようなメッセージキュを利用するにあたって、自動スケーリングによる拡張性と低コストの運用を行えるのがSQSになります。
同じメッセージが1度以上（つまり複数回もありえる）、メッセージの順序を保証しないなどの特徴がありますが、FIFO(First In First Out)というメッセージが重複せず、順序も保証してくれるタイプも出ています。
——————————
マネージドサービスはAWSの要でもありますので、一気に紹介すると多くなってしまうので、この辺で前編を終了したいと思います。
<= To Be Continued…
関連：
雲の呼吸 壱ノ型~AWS設計の勘所：コスト編~
AppiritsのAI研究者が『2020 APN AWS Top Engineers』に選出！資格取得に対する取り組みを紹介！
