AWSインフラ構築学習で、稼働率向上のための具体的な冗長化に初めて取り組んだので、そこで学んだ用語等をメモしておきます。修正点やアドバイス等ございましたら教えていただければ幸いです。
参考講座：AWS：ゼロから実践するAmazon Web Services。手を動かしながらインフラの基礎を習得
そもそも稼働率とは
トラブルなく無事に使えている期間を示すもの。 インフラ設計観点の大切な項目である可用性（サービスを継続的に利用できるか）を表す指標のひとつ。 稼働率の計算には、平均故障間隔（MTBF）や平均修理時間（MTTR）が用いられる。
○平均故障間隔（Mean Time Between Failure）
故障と故障の間隔を表すもの。
○平均修理間隔（Mean Time To Repair）
修理に必要な時間を表すもの。
こんな稼働状況があったら、
平均故障間隔は→ (80時間+120時間+40時間)÷3 = 80時間
平均修理時間は→ (2時間+6時間+4時間)÷3 = 4時間
つまり「平均80時間くらいの間隔で故障する」ということと、「だいたい平均すると4時間が復旧時間として必要」ということが言える。
稼働率の求め方
稼働率は、システムが正常稼働していた割合なので稼働時間(MTBF)÷全運転時間(MTBF+MTTR)で求められる。
今回の場合は、稼働時間240時間÷全運転時間252時間 = 約95%となる
稼働率を上げるための基本的な考え方
そこで、稼働率を高くするためには
①障害発生間隔を長くする or ②平均復旧時間を短くする
の2つが考えられる。そのための手法の一つに冗長化がある。
○冗長化
システムの構成要素を多重化すること。 ある構成要素で障害が発生しても、処理を引き継げるようにすることで稼働率を高める。
「冗長」という言葉は、通常「無駄が多い」のようなネガティブなニュアンスが伴うことがありますが、システムの世界では、冗長であることは「より耐久性が高く、堅牢である」という良い意味を持っている。
○単一障害点（Single Poing Of Failure）
冗長化で重要なのがSPOFの考え方。 SPOFとは、システム構成要素のうち、多重化されておらずそこが停止すると全体が停止してしまう部分のこと。 このSPOFを無くすために、二重化まではやることが多いが、それ以上どの程度コストをかけて冗長化するかは、予算制約と、求める信頼性水準とのせめぎ合い次第らしい。
稼働率を上げる具体的な方法
AWSで取り組める主な方法は2つ
①要素を組み合わせて、全体の稼働率を高める
②負荷を適切なプロビジョニングで回避する
①要素を組み合わせて、全体の稼働率を高める
サーバが2台ある構成。
Active-Active：構成要素が同時に稼働する
Active-Stanby：稼働するのはActiveのみで残りは待機している
Active-Active構成のメリットはダウンタイム時間の短さで、この構成は複数のサーバが同時に動いているため、そのうち一つが動作不能に陥ったとしても、残りのサーバが処理を継続することで、システム全体の停止を防ぐことができる。
それだけ聞いて、全てActive-Activeにしておけば良いのではないかと考えてしまったが、 Webサーバはそれで良くても、DB等のデータを持つものはデータの生合成を保つために同期が必要で、動作が遅くなる等の事象が発生する。そういう時にはActive-Stanbyにしたりするようだ。
②負荷を適切なプロビジョニングで回避する
アクセス数等を予測し、適切にリソースを準備（プロビジョニング）することで、負荷を捌けるようにする方法。ここでは、スケールアップ・スケールアウトが用いられる。
○スケールアップ
・個々の要素の性能を向上させること。 ある程度の規模まではスケールアップがコスパ良いが、一定範囲を超えると悪化する。
○スケールアウト
・個々の要素の数を増やすこと ある程度の規模を超えそうであれば、スケールアウトで対応する。 基本用意するのがN+1構成。安心なのはN=2構成。 （サービス提供に必要な最低限のサーバ台数をNとする）
まとめ
最近アプリケーション制作でも、SQL発行数を減らせるようなコード作りを意識し始めました。 初心者ながら少しでも負荷を下げたり、スムーズな稼働のためにできることはやっていきたいなと思いました。
