Architecting for the Cloud: Best Practices を読んだよ！
とりあえず一通り読んでみたので。まとめ。
大規模システムを作る時
これまでのオンプレだと、データセンター探したり立てたりして、そこにセキュリティつけて、人員雇う。でもって、ラックやらハードウェアやらネットワークやら電源やらを揃えたらやっとシステムを稼動できる、というお金持ち以外は大規模システム作るな、という感じだったけど、AWSだと、Free Tierもあるので、無料で開始できる。課金は使用量に対しての課金だし、設備やそれに対するセキュリティはAWSのサービス一環としてやっているので、こちらとしては、いかに経済的にインスタンスとか、サービスとかを使うか、ということが重要になると理解した。
クラウドを使うことの利点
- 自動化(Scriptable infrastructure)
- オートスケール
- Proactive Scale
- より効果的な開発ライフサイクル
- 向上したテスタビリティ
- Disaster Recovery
開発ライフサイクルがなんでより効果的かというと、今動いているシステムのクローンをちゃちゃっと作れるから。また、世界中の散らばるリージョンや、アベイラビリティゾーンにシステムを散らすことで災害時の事業継続性も担保できる。
誰かが日本にメテオ落としてもアメリカで動かすとかも不可能じゃないですね。
ScalabiliryとElasticity
この辺がピンとくるのに時間がかかってたなぁ。多分こうだろうという理解。
まずこれまでのシステムでもスケール自体はしていた。ドワンゴの社長も「スケール」ということを念頭に考えていると言っていたし。ただ、これまでのスケールは段階的だったし、スケールした以上にリクエストがくると機会損失になっていた、かといってビビりすぎるスケールをしたら過剰投資になっていた。スケール＋Elasticity＝弾力のあるスケール。
EIPとMultiple Availability Zone
EIPは固定のIPアドレスをもらえるやつで、例えば今使っているシステムがおかしくなったら、きちんとしたシステムのクローンを用意してEIPを張り替えれば瞬時に治る、治るって言っていいかわかんないけどそういう運用も可能。FlickrのTictac Releaseとかっていうのを昔聞いたことがあるようなないような、まぁ、そんな感じの運用も可能ですよ、と。
システムを複数のAZに配置してELBで分散しておけば、関東が壊滅しても関西で頑張るみたいなそういうことができる。
セキュリティとかその辺
まず、システムは適宜AMIでスナップショットを取っておく。これをベースにインスタンスの複製が可能になる。Cloud Watchを利用して監視しつつ、ヤバイと思ったら、通知したり、新しいインスタンス作ったりできる。
EBSやRDSを使って、適宜データがバックアップされるようにすることも大事ですね、うん。
インスタンス相互の結合について
各インスタンスがステートフルだったり、インスタンス相互の結びつきが強いと、スケールが難しくなるので、Decoupleする。
例えば、インスタンスのステートはSimple DBに可能な限り逃がしておくとか、レイヤー間の結合は、SQSを使って、非同期にしておくとか。レイヤーをキューで非同期にして疎結合っていうのは、昔JavaWorldで樽澤さんという方の書かれた記事にもあったから、結構伝統的なのかもしれない。
Elasticityの使い方
さてさて、Elasticityの使い方、というか、ようはどういう風にスケールするのかについては、このドキュメントでは３つ提示されてましたね。
定期的にスケールする
毎週水曜日はみんな交通費の精算するとか、毎月２５日は給料の振込みがあるとか、毎週月曜日はみんな鬱で休むとか、そういうことのためにスケールをスケジューリングします。
イベントドリブンにスケール
社長がニュースリリースを売ったとか、この日からあちこちでCM流すよ、とか、WBSで紹介されたとか、こういうのに備えてスケールしておく、というものです、
上記の記事が経緯を詳しく述べているのでいいと思いました。
オンデマンドにスケール
常にシステムを監視しておいて、特定の不可になったらスケールする、という仕組みを作っておく。
並列化
単一のインスタンスで頑張ると５００時間かかるけど、５００インスタンス使えば１時間で終わるよね、という乱暴な理論ですが、Elasticityの恩恵ですね。ただし、処理をスレッドセーフにしないといけません。このドキュメントでは、Share-nothing philosophyと書かれています。並列化は単純にインスタンスを増やせばいいものではないので、設計を慎重にしなくてはいけないでしょう。
データの置き場所
データは必要な場所の近くに置きます。例えば、Webサイトの場合、静的データは、S3に保存してCloud Frontで見せる、Webアプリケーションが使用するDBはEC2インスタンスのすぐ後ろにおくなど。
また、オンプレ環境に構築されたDWHのデータ解析を行うときは、逐一オンプレからAWSに流すのではなく、一括でAWSにアップロードしてから、処理を開始するなど。
考えてみれば当然という気もしますね！
データセキュリティ
セキュリティについても例えばSSLを使いましょう、S3に保存する重要データは、暗号化してからアップロードして、ダウンロード後に複合して使うように決めましょう、とか、ファイルシステムも暗号化しましょう、とかは考えればわかりそうなものですが、このほかにあるのは。。。
クレデンシャルをAMIに保存するのではなく、起動時のパラメータとして設定する、という点でしょうか。なるほど、そういえば、そんな項目あったな。
ちなみに、暗号化、複合化の鍵は厳重に管理しないといけません。鍵がなくなると、全て失うので。
ほかのセキュリティ
ユーザー管理をIAMを使用してやりましょう。確認証情報も定期的に変えましょう。退職の場合なんかは特に気をつけましょう。
ポートの穴あけは最小限にします。Security Group、OSに搭載されたファイアウオール（IP Table、Windows Firewallなどなど）を使いましょう。
大事なことは
既存のノウハウも俄然有効なので、適宜使いましょう。
まとめ
ベストプラクティスはアークテクトを目指すのであれば必携の書であった。