CDPアンチパターンの14つめはバックアップのアンチパターン

今年のクラウドデザインパターンの最大のイベントといえば、ラスベガスでの英語における発表だったでしょう。しかし、東京お台場で9月に行われたクラウドデザインパターンの発表もすばらしいものばかりでした。

そこで、私はアンチパターンのワースト13を発表しました。そのプレゼンの中でも発表しましたが、アンチパターンの目的はただ笑うためにあるものではありません。

• 失敗に陥るパターンを類型化し、事例の早期発見と対応策に関しての提案を目的とする。
• 動作やプロセス、構造について、当初は妥当であったのに、最終的に悪い結果が繰り返されるパターン
• リファクタリングするための方法が存在するパターン

この３つの観点をわすれてはならないと思っています。

１３のアンチパータンの後ろに続くワーストは、バックアップにかかわるものばかりでした。特に、AWSでバックアップを考えるとき便利なのはAMI、EBSとスナップショット機能でしょう。

• 「AMIを一切作らずに本番運用を行う」ことがしばしば見受けられます。これはAMI作りが難しいと思っている場合や、OSからの手順に固執した場合などに見られがちです。ある程度のところまでAMIの形でシステムを用意しておけば、システム構築やトラブル時の対応時間の短縮が可能です。
• 逆に「AMI作成だけがバックアップ」だと思っているとすれば、それも問題です。AMI作成の最大の問題は、AMI作成を動作中に安全に行うことができないことです。また、EBSを使わない場合にはバックアップできないと思っているとすればさらに問題です。
• 「スナップショットを使わない」ことも問題です。EBSによるバックアップは残念ながら完璧ではありません。AWSはEBSが壊れかねないことを表明しています。スナップショットを使えば、異なるアベイラビリティゾーンへの移動や、操作ミスによるファイル消失リスクを下げることもできます。
• 「スナップショットを安全に使えない、使わない」のも時として問題です。EBSはあくまでボリュームでありそのファイルシステムやアプリケーションでキャッシュしている内容はわかりません。スナップショットをバックアップに使うのであれば、ボリュームへの書き込みを確実におこなわければなりません。

繰り返しになりますが、AMI,EBS,スナップショットはAWSでのシステム運用に大きく貢献できる機能です。ぜひこれらの特性を理解して利用しましょう。

さて、13のアンチパターンを見たことがないひとのために復習をしておきます。

1. プロトタイプを作らずに机上だけで設計を行う
2. トラフィック代金を心配しすぎる
3. IPアドレスに頼りすぎる
4. ひとつのアベイラビリティゾーンだけでシステムを作る
5. EC2以外のサービスを使わない
6. S3を共有ストレージ、ブロックストレージとして使う
7. 事前のキャパシティプランニングに固執する
8. AWSのセキュリティ機能を使わない
9. 構築したシステムの見直しをしない
10. 全機能を使おうとして消化不良に陥る
11. リージョン選択を間違う
12. CloudFrontを使わない
13. 実際の負荷変化と違う負荷テストを行う

中でも、机上の設計だけで本番のシステムを決めてしまうことだけは避けましょう！AWSはまだまだ発展していくシステムです。

そして、逆説的ですが、CDPに固執することなく新たなアーキテクチャに挑戦していきましょう。

[slideshare id=14541803&w=427&h=356]

[AWS Summit 2012] クラウドデザインパターン#8 CDP アンチパターン編 from Amazon Web Services Japan