ストーリー仕立てでAWSの勉強を行っています。
導入の第1話はこちらです。
第2話の今回のテーマは「高可用性および事業継続性」です。
なお、ストーリーはフィクションであり、実在の人物・団体とは一切関係ありません。
2話 両得
夜、家に帰宅したAは適当に夕飯を済ませると早速AWSの勉強を始めた。
AWS 認定ソリューションアーキテクト – プロフェッショナル の試験の分野を確認する。
- 高可用性および事業継続性
- 原価計算
- デプロイメントマネージメント
- ネットワーク設計
- データストレージ
- セキュリティ
- 拡張性と伸縮自在性
- クラウド移行およびハイブリッドなアーキテクチャ
『上から順番に勉強していくか。』
最初が「高可用性および事業継続性」。
『何を学んだら良いのかいきなりわからないぞ、、、！？』
とりあえず、AWSの各サービスの概要を確認してみることにした。
『高可用性と言えばサーバーの多重化だな。サーバーを立てるのに使うのはEC2だったはず』
EC2から見ることにした。
https://aws.amazon.com/jp/ec2/
上から改めて読んでみると、「信頼性」という高可用性に関わりそうな項目がある。
EC2の可用性は99.95%を約束、という記述がある。
『サーバーの可用性が数字で出てるんだ。すごい。
もしかして、AWSの「高可用性および事業継続性」を理解するというのは、各サービスのSLAを知ることなのか！？
他のサービスも見てみよう』
続いてストレージサービスのS3を見てみる。
『AmazonといえばS3だよな。S3の可用性ってすごかった気がするな。』
https://aws.amazon.com/jp/s3/
同じく上から読んでいく。
99.999999999%の耐久性と99.99%の可用性があると記述されている。
『へー、99.999999999%の耐久性ってすごいな。
S3使いましょう、99.999999999%の耐久性があります、事業継続性バッチリです、ってお客様に提案できるじゃん！
やっぱり、「高可用性および事業継続性」とは各サービスのSLAを知っていくことで間違いないな。』
同じ要領で様々なサービスの概要を読み続けた。
RDSの1つの「Aurora」の概要を読むと自己復旧機能に関する記述がある。
https://aws.amazon.com/jp/rds/aurora/details/
Auroraには自己復旧機能があり、
ディスクで障害が発生すればバックグラウンドで自動でリペアされる、
また、データベースでクラッシュが発生すれば、それを検出して再起動するようになっており、
可用性が損なわれることはない。
『なるほど、自己復旧機能か。
「高可用性および事業継続性」について知るには、こういう機能についても理解していく必要があるな。』
様々なサービスの概要を読み続けて、気づけば3時になっていた。
多くのサービスのSLAと、いろいろなサービスが持つ高可用性を実現するための仕組みを理解した。
『まだ月曜なのに頑張り過ぎた。
でも「高可用性および事業継続性」についてはバッチリだ。
明日S先輩に今日学んだ事を話そう。
褒められるだろうなー。明日が楽しみだ！』
「早速AWSの勉強始めたのね。行動が早い！」
Aは次の日会社に行くと、すぐに昨日学んだことをS先輩に話した。
「高可用性および事業継続性」として学ぶべき事はズバリ、各サービスのSLAを知ることと、自己修復など各サービスが持つ機能を理解することであると。また、各サービスのSLAや、各サービスが高可用性を実現するために様々な機能のを持つことを。
「昨日の晩だけでそんなに多くのことを学んだのね。すごい。」
『S先輩に褒められた！仕事で使えなくても良い、もう昨日の努力は報われた、、、！』
「でも、それだけだと少し足りないわ。」
「え、、、」
「各サービスのSLAを知る、というのはもちろん大切なことだけど、
「高可用性」を実現するためのアーキテクチャ設計ができるようになることが重要なの。」
「ほーー」
S先輩は具体例を交えて教えてくれた。
「例えば、マルチアベイラビリティゾーン設計ね。」
AWSでは複数のアベイラビティゾーン（データセンター）を使って環境を構築することができる。
オンプレでは手間がかかった、複数データセンターでの冗長構成の構築が簡単にできるのだ。
複数データセンターによる冗長化によって、万が一の地震などの災害に備えることは事業継続性の上でとても重要である。
「シンプルな構成例で説明するわね。」
以下がWebサイトのマルチアベイラビリティゾーン設計の例になる。
まず、2つのアベイラビティゾーンにそれぞれWebサーバーであるEC2を配置する。
フロントにELBを置いてアクセスを、その2つのEC2に振り分けるようにする。
これでまずEC2については、マルチアベイラビリティな設計になる。
続いて、RDSだがこちらはもっと簡単で、RDSのインスタンス作成時にMulti-AZをオンにするだけである。
プライマリーのDBインスタンスとスタンバイのDBインスタンスのデータは常に同期が取られ、
プライマリーのDBインスタンスに障害が発生した場合、自動でスタンバイのDBインスタンスに切り替わる。
これでマルチアベイラビリティなWebサイトが構築できる。
片方のアベイラビリティゾーンが落ちても、サービスを継続して提供できるのである。
「RDSのマルチアベイラビティゾーン対応は、Multi-AZをオンするだけだからとても簡単なんだけど、注意すべきことがたくさんあるの。
まず、Multi-AZをオンにするとDBインスタンスの数が2つになるから、料金が2倍かかるようになるわ。
RDSのインスタンス一覧にはインスタンス1つしかないのに、なぜか2つ分の料金がかかってる、ということが起こり得るので知っておいてね。
あとは、インスタンス切り替え時の動作を理解しておくべき。
切り替えって具体的に何をしているかと言うと、プライマリーインスタンスについてたhostをスタンバイインスタンスに付け替えてるの。
DBのインスタンスが切り替わっても、EC2でDBのIPアドレスをキャッシュしたり、DBとのコネクションを持ち続けたりすると、切り替え後のDBインスタンスに接続できないことが起こり得るから気を付けてね。」
「ほー。
シンプルな例でとてもよくわかります！
複数データセンターでの冗長化をオンプレミスでやろうとすると、
色々やらなきゃいけないことがあって大変ですが、
AWSだとこんなに簡単に実現できるんですね！
おかげさまで「高可用性および事業継続性」については完璧です。」
「完璧。。。
高可用性の実現において、マルチアベイラビリティゾーン設計だけを抑えておけば良いわけじゃないわよ。
複数リージョンアーキテクチャなんかもあるわ。」
「あと、今話したのは「高可用性および事業継続性」のうちの「高可用性」の方だけ。」
高可用性を追求すればコストは高くつく。
コストが高すぎては、当然事業を継続できない。
事業継続性を考慮して、どのレベルの可用性を実現すべきなのかの検討もできるようにならなくてはならない。
「コストまで含めて考えるのが事業継続性ですか。
もっと勉強します！」
AはAWSにおける「高可用性および事業継続性」とは、
単純に各サービスの機能やSLAを理解する事だけではなく、
高可用性を実現するためのアーキテクチャをコスト面まで考慮して設計できるようになる事であると理解した。
「S先輩、丁寧に教えて頂いてありがとうございました！！」
『とても良い勉強になったし、朝からS先輩と話せた。
最高じゃないか！継続して勉強しよう。』
Aの勉強は続く。
。。。ストーリー仕立てで記事書くの慣れないですが、続けます！
次回は「2. 原価計算」の勉強です。
来週の投稿を予定しています。