インフラ設計の非機能要求の考え方

#はじめに
現職でオンプレ→AWS移行のPJに関わっていて、改めてインフラ全般の知識が必要だと感じ始めました。
再度１から鍛え直すつもりで、この記事を書いていくので「当たり前じゃん」って部分もあるかと思いますがさらっと読んでもらえればと思います。

#インフラとは
そもそもインフラってなんぞや？
大雑把に言うと、動いて当たり前のものです。
電気や水道、ガスなどのような社会インフラと呼ばれるものと同じで
などアプリケーションが動く前提として当たり前に動いていないといけないもの全般のことを指します。

なのでITの分野では
サーバーやネットワーク、ミドルウェア
あたりがインフラエンジニアの主な領域と言えます。
(組織によってはもっと広い意味で捉えられることもあります。)

#インフラ設計の非機能4要素
インフラ設計においては大きく以下について考える必要があります。
・可用性
・運用、保守性
・セキュリティ
・移行性

一つずつ見ていきましょう。

#可用性
システムが動き続けるためには可用性の設計が必要です。
インフラは動いて当たり前、とみなされています。
なので、可用性がまず一番の重要な要素です。

##可用性ってなんだっけ？
はい、私も可用性を答えるためには毎回ググっています。。。
それくらいわかっているようで、答え辛い抽象的な言葉ですよね。
一つずつ丁寧にみていきましょう。

可用性を大雑把に一言で言ううと、動き続ける力のことです。
先に「インフラは動いて当たり前」と書きました。
つまりはインフラ設計の大部分はこの可用性が関わってきます。

可用性とは具体的に以下の観点で分けられます。
・継続性
・耐障害性
・回復性
・災害対策

##継続性
まず「継続性」についてみてきます。
一般的な用語だと「稼働率」に表されます。

稼働率＝実際にサービスを利用できた時間/サービスを提供すべき時間の割合です。

例えばサービスを24時間３６５日稼働させるべきシステムがあったとします。
このシステムで障害によるサービス断が月に３０時間あった場合
月の稼働率は(24H✖️30日 - ３０H)/24H✖️30日 なので、95.8%ほどです。

この数字が高いか低いかはインフラ上で提供されるサービスやシステムにもよります。

基本的に障害は起こるものです。
なので、「企業としてどこまでそれを許容するのか」を決めていきます。
例えばECサイトなどであれば２４時間365日稼働し続ける必要があるので、稼働率は限りなく100%に近づける必要があります。
逆に社内向けの情報発信サイトであれば、障害で稼働しない時間があったとしても多少は許容できますよね。

基本的に稼働率を上げようとすればコストは上がります。
なので、そこまでガチガチに継続率を意識しなくてもいいシステムであれば、コスト見合いでこの継続率を調整していくやり方になるかと思います。

##耐障害性
続いて「耐障害性」についてみてみます。
これは早い話が冗長構成のことです。

単一障害が起こった場合にも耐えられるように2台構成にするのか、電源は分けるのか、ネットワークは分けるのかなど、インフラのあらゆる部分の障害に対して、考えていきます。
全てを冗長化するのが望ましいのは明らかですが、これもコスト見合いで何を冗長化するのか決めていきます。

##回復性
続いて「回復性」です。
これは障害が発生してからどれだけの時間で復旧するのか、いつの時点に復旧するのかの観点です。
俗にいうRTOとRPOですね。

・RTO(Recovery Time Objective)・・・目標復旧時間
・RPO(Recovery Point Objective)・・・目標復旧時点

例えば業務系のシステムであれば早く復旧してほしいし、復旧時点も可能な限り最新が目標となります。
業務影響のないシステム（安否確認システム、給与明細システム）とかであれば急を要さないので、復旧時間もある程度許容できるものもあるでしょう。

##災害対策
最後に「災害対策」です。
これは耐障害性の拡張版のようなイメージです。
冗長構成を組むとしても、同じデータセンターにあった場合そのデータセンターが災害や隕石落下などで潰れてしまった場合、冗長化もクソもなくなってしまいます。
そんな時にある程度地理的に離れた場所にバックアップをとっておくことで、データセンターが潰れた場合にバックアップ拠点でリカバリーをして業務継続するような対策のことです。
いわゆるBCP(Business continuity planninng)ってやつです。

一般的に業務継続性を維持するシステムのみ実施することが多いです。

#運用保守性
運用と保守って違いがよくわからん、という人もいると思うので簡単に定義します。
運用・・・システムを継続的に稼働させるために行う作業
保守・・・バグ改修や機器のリプレースなどシステムに変更を加える作業

ただこの定義は会社や契約によってもまちまちなので、対応することになったらどこまでを定義とするのかは明確に運用設計や契約時に確認しておく必要があります。

運用保守を設計する上での項目として以下があります。
・通常運用(監視、バックアップ、定例作業)
・保守運用(パッチ適用、メンテナンス対応、証明書更新など)
・障害時運用(障害対応、エスカレーションフロー、障害レベルによる通知など)
・運用体制(リモート/常駐、人数、対応時間など)
・その他運用方針

それぞれの項目に対して、SLAを実現するための体制とコストなど協議していきます。
バックアップは頻度、世代、容量などを考慮しつつお客さんと合意形成しながら定義していきます。

#セキュリティ
セキュリティはシステムの安全性を担保するために昨今特に重要視されています。
気をつけるべき点は多岐に渡るので、ここではポイントに絞ります

##アクセス制限
誰が何をできるのか、を制限することです。
仮に認証した人が誰でも使える、という設定になっていたら、万が一IDが乗っ取られた時に全システムが影響を受けてしまいます。
そうならないためにも、基本的な考えとして最小限のアクセス制限を実施します。

・システムそのもののアクセス制限
・システム内での利用制限
・送信元IP制御
などなど

このような適切な権限管理をすることで、万一乗っ取られた場合にも被害を最小限にするような設計が必要です。

##データ暗号化
データを適切に暗号化していないと、万が一乗っ取られた場合に丸ごと情報を奪われてしまいます。
適切なデータ保護の観点から暗号化は必須です。

##マルウェア対策
ネット上は常に脅威に晒されていると思った方がいいでしょう、
そんな悪意あるプログラムなどから守るためにトレンドマイクロなどのセキュリティ対策ソフトを入れることをオススメします。
このようなセキュリティ対策ソフトはディスクをスキャンして脅威がないかを確認します。
主に以下の２種類
・リアルタイムスキャン
　→新たにファイルが生成されたりダウンロードされたりする際にリアルタイムでスキャンします。
　　すぐにセキュリティ異常が分かるが、PCの処理負担はかかる。
・定期フルスキャン
　→定期的に全ファイルのスキャンを実施する。時間もかかり負荷もかかるので業務時間外に実施することが通常

ウイルス対策ソフトも完璧ではありません。常にエンジンやパターンファイルは最新化しておく必要があります。

##ネットワーク対策
FWなどで不審なIPアドレスやポートへの接続を遮断しておくことで、脅威から阻害することができます。

#移行性
現行システムから新システムへの移行についての要求を定義していきます。
ここでは設計というよりかはユーザの要求を整理することが重要です。
以下が移行性の項目となります。
・移行時期
・移行方式
・移行対象
・移行計画

##移行時期
・旧→新への切替はどれくらいの期間かかるのか、
・並行稼働の時期はあるのか、
・旧システムを停止する必要はあるのか
また、システム停止して良い時間帯や日付を抑えておくことも必要です。

##移行方式
一斉に切り替える、もしくは順次に切り替える方式があります。
順次移行の場合、
例えば拠点ごとに切り替えていく方式や、業務単位で切り替えていく方式など様々な分け方が考えられます。

ここで注意なのが、順次移行の方がリスクが低いように見えますが、並行稼働期間もあるため難易度は高いです。

##移行対象
どのシステムを移行して、どのシステムをリタイアするのかを選定します。
またデータ単位でもこの種類は不要、なども選定していきます。
HWリプレースであれば基本全て移行になると思いますが、アプリのバージョンアップであれば移行しないデータもあるかもしれないので、確認が必要です。

##移行計画
時期、方式、対象が決まったら、
・どのシステムから切り替えていくのか
・時間帯は日中か夜間か休日か
・並行稼働期間を設けるか
・旧システムの停止はいつにするか
・切り替えに失敗した場合の切り戻し
・動作確認をどこまで実施するのか
などの実態に即した計画を策定していきます。

#参考資料
インフラ設計のセオリー