プリンシプルプログラミング プログラミング

【POP36】アーキテクチャ非機能要件④信頼性について

はじめに

この記事は「プリンシプルオブプログラミング 3年目までに身につけたい一生役立つ101の原理原則」を読んだ際に記した議事録です。

著作権の関係により、詳細には書きません。詳しい詳細を知りたい方はぜひ本書を読んでみてください。

プリンシプルオブプログラミングをPOPと訳します。

What : いかなる状況でもソフトウェアが機能を維持する能力

例外的な場面、予期しない方法や不正を受けてもソフトウェアが機能を維持し続ける能力のことです。

信頼性には主に以下の二つがあります。

フォールトトレランス

障害が発生した際に、正常な動作を保ち続ける能力のことです。障害が発生しても、動作を保ち、且つ内部的には修正を行います。

通信障害が発生しても、一旦接続を切り、その後再接続を行うなどしてソフトウェアの復旧を行います。

ロバストネス

不正を受けたり、使用方法のミスを受けてもソフトウェアを保護する能力のことです。

例えば不正なURLを打ち込まれても「404ページ」に飛ぶといった動作のことです。

Why : 求められている機能維持レベルは様々だから

ソフトウェア毎で求められている機能維持レベルは異なります。例えば大規模システムの場合、システム障害によるサービス利用停止は許されません。大規模な損害になってしまいます。ですので、規模を縮小してでもサービスを継続する必要性があります。

一方、個人のソフトウェアの場合、そこまで高い機能維持レベルは求められません。危険な状態で機能を維持し続けるよりも、データを保全し、再起動した方が良い。コストを抑えたいからそこまで機能維持レベルを高くしなくて良いなどです。

これらのレベルはあらかじめ、要件定義で明確にして、それらに沿ったアーキテクチャ設計を行う必要があります。

How : 「冗長化」「フェールソフト」「フェールセーフ」

フォールトトレランス観点の対策としては、アーキテクチャに内部的な冗長性(二重化)をもたせる「冗長化」を行ったり、障害発生時に、機能を制限して処理継続を優先させる設計「フェールソフト」を考慮する対策を行います。

ロバストハネス観点の対策としては障害発生時に、その部分を切り離す「フェールセーフ」を検討します。

終わりに

この記事ではプリンシプルオブプログラミング 3年目までに身につけたい一生役立つ101の原理原則の議事録を自分用に記しています。

この記事ではカバーしきれていない部分も多いので、是非本書を手にとって読んでみてください。

次回、「【POP37】アーキテクチャ非機能要件⑤テスト容易性について」です。ぜひ、次の記事も読んでみてください。

  • この記事を書いた人
  • 最新記事

ミッチー

小中高と野球漬けの毎日 ▶︎ 大学時に自分が何もできないことに気づき、プログラミング学習開始 ▶︎ PCは疎かったがめげずに継続 ▶︎ 受託で案件を頂きながら、オーダースーツ事業に、通販事業にも参戦 ▶︎ 東証一部Web系自社開発企業にエンジニアとして内定。

-プリンシプルプログラミング, プログラミング

© 2022 オミチャンネル Powered by AFFINGER5