寄稿：米国サイオス VP Cassius Rhue
※この記事は翻訳されたものです。本記事の原文はこちら
米国サイオスで、カスタマーエクスペリエンス担当としてバイスプレジデントをしているCassius Rhueです。この記事では高可用性に関する13の真実をご紹介します。貴社システムの運用で当てはまることが1つでもないか、ぜひ確認してみてください。
Contents
1.ハイパーバイザーHAはアプリケーションHAと同じではない
ハードウェアまたはハイパーバイザーに冗長性があるから、可用性が高いと誤解している人が多いですが、ハードウェアやハイパーバイザーの冗長性は、アプリケーションの高可用性を保証するものではありません。また、障害発生時にアプリケーションのオーケストレーションが適切に実行されることを保証するものでもありません。
2.高可用性においては、「大きい」ことは「良いこと」ではない
パワーリフティングでは、より重いウェイト、より少ないレップが良いとされています。あるいは、ハグ（ハグとは、しばらく会っていなかった別の町の友人に会った時にかつてしていた動作ですが、覚えていますか？）も、大げさなほうがいいです。でも、大きいことが必ずしも良いとは限りません。
たとえば、大きな腎臓結石は間違いなく良いものではないでしょう。高可用性においては、より大規模でより複雑なソリューションを構築しても、必ずしも高可用性が向上するとは限りません。それどころか、可用性が同程度かそれ以下である可能性もあります。また、より大規模でより複雑なシステムを構築すると、障害時により多くのことに対応しなければならくなる場合もあります。
3.あらゆる場所で障害が発生する…こともある
アプリケーションプログラミング言語の歴史は1950年代にまでさかのぼります。そして、言語、プロセッサー、IDE、コードの品質は向上しましたが、「すべてのアプリケーションにおいて、ある時点で障害が起きる」というのが現実です。
例外、バグ、未処理での終了、偶発的な終了、リソースの枯渇などによる障害が発生します。アクティブ/アクティブ、またはアクティブ/パッシブなアプリケーションの可用性戦略を策定することは、依然として必要なのです。
4.「どのように」だけでなく「なぜ」にも注目する
仕事を早く終わらせたいという人間の自然な傾向は必要な資質ですが、「なぜ」という質問に答えることによって、はやる気持ちを抑え、コントロールする必要があります。ビジネス、アプリケーション、データベース、ステークホルダーの要件を理解せずにソリューションを追加すると、次のいずれかを引き起こします。
- 障害
- 支出超過
- パフォーマンスの低下
- 混乱と過剰なアーキテクチャ
- 上記のすべて
可用性を確保することだけに注力するのではなく、ビジネスニーズや「Why」の答えを理解するためにリソースと労力を費やすことが大切です。
5.パッチの未適用による問題は、後悔の原因になりやすい
やったこともやらなかったことも、すべて結果に表れます。パッチの未適用による問題の結果は、すべて後悔です。私はカスタマーエクスペリエンス担当バイスプレジデントとして、お客様が既知の問題にタイムリーに対処しなかったためにダウンタイムが発生するのを目の当たりにしてきました。
6.文書化されていない問題もダウンタイムの原因に
次のような場面を思い浮かべてみてください。新任の管理者がネットワーク上のサーバーを調べています。使用状況レポートによると、そのサーバーは稼働しておらず、クライアントも接続されていません。新しい管理者はサーバーを認識できず、「タグ」、ドキュメント、またはその他の識別子も見つからないため、そのサーバーをシャットダウンする必要があると考えました。不幸にも、文書化されておらず誰も知らないインスタンスは実際にはスタンバイサーバーであり、その削除により、プライマリーサーバーが予期せずクラッシュした場合には、ダウンタイムが発生します。
これは架空の話ではなく、ある新任管理者がサーバーを誤ってQAシステムであると認識し、パッチ適用前にシャットダウンしてしまったという実際にあった話です。
7.自己満足も敵
オンプレミスでもクラウドでも、あるいはその混在でも、可用性が「一旦設定したらあとは放置」というものであれば、誰もがそうしたいと思うでしょう。しかしこの世界には、「設定したらあとは放置」というような単純なことはほとんどありません。
将来の可用性の最大の敵の1つは、現在の高可用性の成功です。災害が少なく、チームが安定した状態を維持できているという自信を持てるようになると、自己満足に陥ってしまいます。成功すると、その状態が続くと思ってしまいがちですが、高可用性に対する自己満足は高可用性の敵なのです。企業の周りや企業内の状況は変化しています。クラウドも、ビジネスニーズも、アプリケーションやオペレーティングシステムも変化しています。
8.変えるのは大変
変化は難しいものです。寝る前に2切れ目のケーキを食べるのをやめたいと思いつつやめられない、甘いもの好きの人に聞いてみてください。
高可用性においても同様の難しさがあります。災害を経験したチームでさえ、たとえその変化が良いものであっても、変化には消極的になりがちです。彼らには、ビジョン、理由の理解、そしてサポートが必要です。また、ソリューションが確立されているチームでも、不安定さが生じたり、新たなリスクにさらされたりすることを恐れて、高可用性の向上に消極的になります。
9.すべての変更が良いとは限らない
良い方向への変化であれば、何かを変えることは良いことです。より高い可用性のソリューションやアーキテクチャへの変更を検討する際には、目標や要件に照らし合わせて分析し、可用性向上の範囲内で変更を行うことが重要です。変更する際には、安定性を高め、重要なコンポーネントの保護を追加し、回避策を排除し、サービスの可用性を最適化して、徹底的にテストしてください。
10.安いからいいというわけではない
安ければ良いというわけではありません。安価なソリューションは低価格であるのと引き換えに多くの制限があり、理想的とは言えません。そして安価なソリューションでは、アプリケーションを考慮していない、オーケストレーションに制限がある、隠れた複雑さがある、手動でのリカバリーやフェールオーバーが必要である、ユーザーの検証が制限されている（または行われていない）など、不足している機能があることに注意してください。
また、安いソリューションには、カスタマーサポートが含まれていない場合もあります。ソリューションにサポートが含まれているのか、それともサポートを利用するには高額の追加費用が必要になるのかを必ず確認しましょう。
同じことが、計算能力、ディスク、ストレージを削減した安価なデプロイメントにも当てはまります。価格や月々のコストは下がるかもしれませんが、ソリューションのキャパシティは理想的とは言えないものになる可能性があります。
11.うるさいからといって効果があるわけではない
オオカミ少年の話はご存知でしょうか。嵐のようなアラートを発生させるアプリケーション監視ソリューションは、遅かれ早かれ無視されるソリューションとなります。
アラートを提供するソリューションを持つことは素晴らしいことですが、そのソリューションが誤って、あるいは過剰に重要なアラートを発生させてしまったら、効果がなくなります。
12.高可用性は、単なる製品やハードウェアのソリューションではなく、文化やマインドセット
ソフトウェア、ハードウェア、プロセス、ソリューション、およびサービスはすべて、高可用性の一部です。しかし、IT部門と事業部門の間で合意が得られなければ、高可用性には不満がつきまとい、価値、ビジネスの安定性、顧客満足度の向上、リスクの低減などの議論ではなく、常に予算の議論が行われることになります。
13.今からでも遅くはない
希望は高可用性のための戦略ではありません。また、甚大な災害やアプリケーションの障害が起こらないように願うことも戦略ではありません。可用性の高いエンタープライズアーキテクチャの設計と構築は、たとえ前回の災害から数週間、数か月経っていたとしても、今すぐ実現することができます。
ご利用のアプリケーションの可用性を高めたいとお考えでしたら、サイオステクノロジーまでお問い合わせください。
– カスタマーエクスペリエンス担当バイスプレジデントCassius Rhue
—-
日本のサイオステクノロジーで提供中の高可用性ソリューションはこちらをご覧ください。
ワールドクラスのHAクラスタソフト「LifeKeeper」
https://bccs.sios.jp/lifekeeper/
Pacemaker・DRBDなどのOSSをもとにした可用性向上「Linbitクラスタスタックサポート」
https://bccs.sios.jp/linbit/
