基礎講座　第４回「冗長化ってどう考えればいいの？」

冗長化と聞いてどんな印象を受けますか？

IT業界に長くいる人にとってはあまり違和感を感じないかもしれませんが、

よくよく考えると若干疑問がわかなくもないです。

というのも、冗長の本来の意味は

「文章・話などが、無駄が多くて長いこと。」（goo辞書デジタル大辞泉）

なので、少なくともあまりいいイメージではない言葉です。

もし、「現行システムは冗長化されていないため、来期予算に

『システムの冗長化』として10,000千円計上します」と

IT業界の用語に慣れていない経営者に決裁を求めて「冗長化」をIT業界で使う意味ではなく

「無駄が多い」という意味に捉えられてしまったらどうでしょう。

この「冗長」という言葉からすると、なんか無駄な予算のような気がする

と誤解され、却下されそうな気がしませんか？

そんなとき、

「冗長って無駄があるという意味でしょう、ならば予算もないのでとりあえずシングルで。」

で、本当に大丈夫でしょうか？

それでは「冗長化」をテーマに基礎講座の第4回目をはじめます。

図１）の通り、オンプレミス環境とクラウドの間を繋ぐ閉域接続の

ネットワーク部分を対象に、冗長化の話をしたいと思います。

目次

• 冗長化の必要性
• 障害が起きなくてもシステムが止まることがある
• 冗長化の構成
• まとめ

冗長化の必要性

クラウドを利用するとき、クラウドにのせるシステムはどんなシステムでしょうか？

今や何をクラウドにのせるかというよりも、何をのせないかを

考える方が多いのかもしれません。そのくらい、多くの重要なシステムで

クラウドの活用が進んでいるかと思います。

Amazon.comの最高技術責任者兼副社長ワーナー・ヴォゲルス氏は、

「すべてのものは壊れうる」と言っています。

また、AWSでは「Design for Failure」とも表現され、壊れることを

前提にシステムを設計しましょうという考え方をしています。

止まっても自分たち（自社）がちょっと不便になるだけとか、

短時間であれば人海戦術等別の手段でなんとかなるという確証が得られているなら

冗長化は考えなくてもよいかもしれません。

一方で生産管理、在庫管理、販売管理、財務・会計、受発注管理

などといった所謂ミッションクリティカルと呼ばれる

基幹系システムであれば、システムの停止はイコール企業活動の停止

を意味する事態となってしまいます。

企業活動を止めてはいけないのであれば、その企業活動を動かして

いるシステムの冗長化を全く考えないという選択肢はないと思います。

そういったシステムは冗長化が必要です。

反対に、冗長化しなくてもいい場合はどんなシステムでしょうか？

例えば、

・検証環境、テスト環境、開発環境などネットワークで停止が許容できる場合

・そのシステムが止まっても、何らかの別の代替手段があるなど実害が発生しない場合

といったケースなら、冗長化は不要かもしれません。

なので、こういったケースに当てはまれば冗長化は不要と考えられますが、

そうでない限りは、冗長化の必要性が高いと言えるでしょう。

障害が起きなくてもシステムが止まることがある

障害が発生することを前提にシステムを設計しましょうと書きましたが、

もうひとつ重要なことがあります。

「システムが止まる原因は障害だけではない」ということです。

障害ではないのにシステムが止まるのはどんなときでしょうか？

それは「計画停止」です。

よくメンテナンスといいますが、この言葉はあいまいです。

なぜなら、システムを止めずにおこなうメンテナンスもあると思いますので、

この言葉だけでは止まるのか止まらないのかわからないからです。

そう、メンテナンスは無停止でやるものもあれば、停止してやるものも

あります。再起動が必要かもしれません。

なので、ここでは止まるという意味で「計画停止」と言うことにします。

どのくらいの頻度で発生するかは別としても、クラウドだって計画停止することもあります。

障害が発生しない限りは一切止まらないわけではありません。

むしろ障害が起こらなくても止まることがあることも想定に入れておく必要があるのです。

冗長化の構成

それでは、AWSへ接続する場合を例に、どのような構成で冗長化するのかを見てみましょう。

図２）の通り、オンプレミスから異なる２つのAWS Direct Connect（以下Direct Connect）の

ロケーションを経由してAWSへつなぎます。

Direct Connectを2本ひくことになります。

Direct Connect はオンプレ環境とAWSを直接結ぶわけではなく、Direct Connectロケーション経由で

接続することになる以上、そのDirect Connectロケーションでの何らかの障害に備え、冗長化を図ります。

この構成でSLA99.9%です。
SLA（Service Level Agreement：サービス品質保証/サービスレベル合意書）

では、１つのDirect ConnectロケーションでDirect Connect１本だったらどうでしょう。

これはAWSの推奨ではないため、SLA対象外となってしまいます。

次に図３）です。オンプレミスから異なる２つのDirect Connectのロケーションを

経由してAWSへつなぐのは図２と同じで、各ロケーション2本ずつの計4本のDirect Connectを引く構成です。

この構成でSLA99.99%です。

図３）までいったらお腹いっぱいな感じもしますが、さらにより高い可用性を求めるなら、図４）です。

図４）は具体的にロケーションの名前も記載されていますが、CC１から東京リージョンへつなぎ、

異なるロケーションかつ地理的にも離れた大阪のOS1から大阪リージョンへと接続する構成です。

災害復旧から復旧することを、そのための体制・仕組みも含めてディザスタリカバリ（以下DR）と言いますが、

DRまで想定し、首都圏直下型地震等で東京リージョンがすべて機能しなくなった場合でも対応できる構成です。

なお、この資料が発表された時点ではまだ大阪リージョンはローカルリージョンという位置づけでしたが、

現在はフルリージョンとなっています。

いずれにしても、システムの重要度、止まったときの影響度などと予算的なバランスを見ながら、

どこまでの備えを用意しておくかを判断して構成を決めることになるかと思います。

<参考資料>

AWS Direct Connect回復性に関する推奨事項

https://aws.amazon.com/jp/directconnect/resiliency-recommendation/

AWS Direct ConnectのSLAについての詳細は、こちらをご覧ください。

https://aws.amazon.com/jp/directconnect/sla/

まとめ

　（１）冗長化の必要性

　⇒「すべてのものは壊れうる」ことを前提に、

　下記に当てはまる場合以外は原則として冗長化を考える。

• 検証環境、テスト環境、開発環境などネットワークで停止が許容できる場合
• 何らかの代替手段があるなど実害が発生しない場合

　（２）計画停止も想定

　⇒障害が起きなくても計画停止で止まることがあるので、想定に入れて考えておく。

　（３）冗長化の構成

　　⇒図２）～図４）の通り。

　システムの重要度、止まったときの影響度など、予算的なバランスを見ながら、

　どこまでの備えを用意しておくかを判断して構成を決める。

ブログの内容が冗長化を検討する際に少しでもお役に立てれば幸いです。

それではまた！

この記事を書いた人　@Sherpa

同じカテゴリーの記事