このエントリは、随筆風にだらだら書きたいと思います。
(なんとなくそういう気分だからです)

このブログの過去エントリを翻ってみると、
はじめてAWSに関するエントリを書いたのが2012年11月。
実際に使い始めたのはもっと前からなので、
AWSを扱い始めてから、もう5年以上過ぎていることになります。

AWSの進化は速く、
この5年の間にいろいろなサービスがリリースされました。
ですが、同時に、基本的な考え方は変わってないなとも思っています。

このエントリでは、
私がAWSでシステム構成を考えるときに気をつけていることを、
(その中でも特にずっと変わっていないこと)
改めてまとめてみたいと思います。

消えて困るものはとにかくS3

昔から、JAWS-UG (AWS User Group - Japan)で登壇者は、
自分の好きなAWSのサービスを言う習慣がありますが。
私は好きなサービスの一つは「S3」です。

S3は、安い・簡単・便利を兼ね備えたサービスで、
「とりあえず、消えたら困る物はひたすらS3に入れておく」
ということを意識してシステム構成を設計すると、
ある程度、バックアップの要件を満たすことが出来るようになるはずです。

RDSのデータは、バックアップの形でS3へ。
ファイルやリポジトリも、定期的にS3に同期。
ELB等のログもS3へ。
EC2で動いているミドルウェア・アプリケーションのログはCloudWatchLogsでS3へ。
EC2のイメージはAMIでS3へ。
ビルドしたアプリケーションのイメージもS3へ。

というような感じで、消えて困るものの最終的な行き先をひたすらS3にしておきます。

S3に置いておきさえすれば、
AWS側で三カ所以上にコピーして保存されるので、基本的に消える心配はありません。

システム上で、何らかのデータが発生する場面があれば、
そのデータが消滅してよいもので無い場合を除いて、
最終的にS3に行っているかをチェックするのは大切なポイントだと思います。

EC2は使い捨てる

AWSを使うとEC2を使ってアプリケーションサーバを構築することになりますが、
残念ながらEC2は、
一般的なUNIXサーバ機と比較して高稼働率の(可用性の高い)サーバとは言えません。

突然、動かなくなって再構築が必要になることがある前提で、使う方が無難です。

「消えて困るものはとにかくS3」の考え方を徹底しておけば、
EC2のインスタンスが動かなくなった場合でも、
壊れたインスタンスのストレージからデータを抽出する作業などは必要はなくなっているはずです。

あとは、壊れたEC2と同じインスタンスを立ち上げ直すことができるようにしておけば、
EC2を使い捨てで使うことが出来るようになります。

壊れたEC2と同じインスタンスを立ち上げるには、
構築済みのEC2のイメージをAMIとしてS3に保存しておく、
インスタンスを構築するcloud-initのスクリプトを用意しておく、
などの方法があります。

個人的には、cloud-initのスクリプトを用意して、
そのスクリプトでEC2のインスタンスを起動するようにAutoScalingグループを構成するのが好きです。
必要なインスタンスが1台であってもAutoScalingグループに入れておけば、
インスタンスが壊れた時に、自動的に復旧させることができます。

そして、アプリケーションをデプロイする場合も、
AutoScalingグループまるごと新しいものを作って有効化、古いものは破棄でOKです。

EC2インスタンスのこういった使い方が、
俗に言うImmutable Infrastructureってやつですね。

EC2同士を直結しない

私が3つ目に気をつけていることは、EC2のインスタンス同士を直結しないということです。

どういうことかを、Webアプリケーションの場合を例に説明すると。
Webサーバ(EC2)→WebAPサーバ(EC2)→DBサーバ(EC2)
という形ではなく、
ELB→Webサーバ(EC2)→ELB→WebAPサーバ(EC2)→RDS
というように、EC2とEC2の間には、AWSが提供するEC2以外のサービスを挟むということです。

他の例を上げると、
WebAPサーバが受け付けた要求を、バッチサーバで非同期に実行する場合は、SQSを挟みます。
WebAPサーバ(EC2)→SQS→バッチサーバ(EC2)
※大きなデータを受け渡す必要があれば RDSやS3経由で渡します。

このようにEC2を直結しないことで、EC2の特定のインスタンスへの依存性を下げることができます。

他の処理がEC2の特定のインスタンスに依存していると、
「EC2は使い捨てる」ことが難しくなるので、この点を意識して構成を組むようにします。

AutoScalingなどを話題にするとサーバの増設が取り上げられがちですが、
どうやって減設するか考えておかないと、
EC2のインスタンスを停止できなくなり、
必要な時に必要なだけ使うクラウドのコストメリットを得られなくなってしまいます。

EC2のインスタンスを作るときは、そのインスタンスを停止しやすくするために、
その手前に何かAWSの他のサービスを置くことができないかを考えてみると良いと思います。
ちなみに、置くものが見つからない時の最後の手段は「ElasticIP」です。

まとめ

今のAWSでは、
S3よりも安いストレージが出てきたり、
dockerのコンテナを扱いやすくなったりなど、
ここで書いた方法よりもbetterな方法はいくつも出てきているとは思います。

ですが、
クラウドのメリットを享受するために考えなければいけないこと、
という意味では、基本的な考え方は変わっていないのかなと思っています。

以上、AWSを使う皆様にとって、少しでも参考になれば嬉しいです。

ちなみに、このエントリは、
私は好きなAWSのサービスが「S3」と「ElasticIP」である説明にもなっていたりします。
好きなものを語るときは、随筆風の方がいいかなと思って。。