コーポレートサイトの可用性、拡張性をさらに高める方法の一つとして、「疎結合」が挙げられます。ここでいう疎結合とは、互いに過度に依存し合わないコンポーネントを構築し、あるコンポーネントが故障したり、反応しなくなったり、反応が遅くなったりしても、別のコンポーネントを生成し、システム全体としては障害が生じていないかのように処理を継続することです。

　実はこれまでに強化してきたコーポレートサイトでも、ELB（Elastic Load Balancing）によってWeb・APサーバーを疎結合化しています。Web・APサーバーの1台に障害が発生したとき、ELBが検知してそのサーバーにトラフィックを流さないようにして、システム全体として処理を継続します。

　スケーリングでは、Web・APサーバーの仮想マシンを新規作成してELBに登録するだけです。その際、DNS（Domain Name System）のレコードはELBを参照するようにしておくことで、設定変更の必要がなくなります。DNSサーバーに登録するのはELBの情報だけ。Web・APサーバーを登録する必要はありません。

　ELBが無いとDNSサーバーに全てのWeb・APサーバーの情報を登録する必要があり、仮想マシンの追加や故障のたびにDNSレコードを更新しなければなりません。

　疎結合はメインフレーム全盛の時代から脈々と続いてきた考え方ですが、AWSをはじめとするパブリッククラウドではELBのようなサービスによって疎結合化を進めやすくなっています。

　今回は、疎結合化を進めるうえでカギとなるAWSのサービスとして、メッセージキューイングの「Amazon SQS（Simple Queue Service）」とプッシュ配信の「Amazon SNS（Simple Notification Service）」を取り上げます。

キューでRDBの負荷急増を回避する

　メッセージキューイングはメインフレームの時代からある概念で「MQ（エムキュー）」と略されます。二つのコンポーネントがメッセージをやり取りする際に、メッセージを格納するキューを介する仕組みです。送信側はキューにメッセージを送り、受信側はキューに問い合わせて受け取ります。この仕組みにより、システム全体の可用性と拡張性を高めます。

　例えば、コーポレートサイトで人気のある景品を時間限定でプレゼントするとします。申し込みのアクセスが殺到すると、リレーショナルデータベース（RDB）の性能によっては負荷に耐えられなくなります。

　このときMQを使うと、キューがメッセージ（ユーザーからのリクエスト）のバッファーになります。キューはメッセージを並行して受信しためていき、受信側はキューにたまったメッセージを順次取り出して処理しRDBにアクセスするので、負荷が平準化されます。受信側が一時的に停止しても、メッセージはキューにたまっており、復旧したとき処理を再開できる利点もあります。

　ここまでの説明で、キューに障害が起きるとシステム停止やデータ消失につながるのでは、と思ったかもしれません。その考えは正しく、オンプレミス（自社所有）環境ではキューの可用性やサイジングを管理する必要がありました。

　これに対してAWSでは、Amazon SQSというMQのサービスを提供しています。マネージドサービスで、サイジングや運用管理の大部分をAWSが行います。

　なお2017年11月28日（米国時間）に、年次カンファレンスのre:Invent 2017で「Amazon MQ」というMQの新サービスが登場しました。「Apache ActiveMQ」というオープンソースソフトをベースにしており、対応プロトコルが多く、オンプレミス環境から移行しやすいという特徴があります。ただし東京リージョンではまだ使えないので、ここではSQSに絞って説明します。