アベイラビリティの指標

ペイメントサービスの業務特性（クライアントに７×24の金融決済サービス提供）により、ペイメントサービスのアベイラビリティはペイメントサービスプロバイダーのサービスを評価する最も重要な指標の一つになっている。
アベイラビリティ（可用性）とは、特定の時間帯の中でサービスが使えない時間の比率であり、サービスの安定性と連続性を測る指標である。業界の中で一般的に比率を計算しており、例えば99.9%，99.99%，99.999%などで表示する。このアベイラビリティの指標でサービスの故障時間を分かりやすく表示できる。
下記の図は、1年間のアベイラビリティの比率の各数値が反映する対照故障時間を表している。

実際の業務の中で100％のアベイラビリティを実現することは不可能であるが、無限に100％へ近づけるようにするのは全ての会社が努力しているものである。アベイラビリティの計算方法も単純に故障時間対合計時間の割合ではなく、異なる業務シーンでは異なる計算方法がある。これはビジネスモデル、故障時間、故障業務比重などにより差異が出てくる。
アベイラビリティの目標は対応チームの技術能力を十分反映するが、違う角度から見たとき高いアベイラビリティの目標の設定は対応コストの増加も意味する。アベイラビリティの目標が高ければ高いほど、それを実現するためのコストも高くなる。ですので、アベイラビリティの目標設定の時には対応チームの技術能力を考慮する一方、コストの投入も考慮しなければいけない。
縦割りで見た時に、アベイラビリティの目標実現は二つのパートがあり、それぞれアプリケーションとインフラのアベイラビリティである。また、アベイラビリティを影響する要素は非常に多いが、次のように大きく三つの分類ができる。アプリケーションそのものの故障、インフラそのものの故障及び人的操作による故障である。アプリケーション故障、人的操作故障に関しては各々の会社ではそれぞれの応急処置があるかと思いますので、本文ではインフラ故障があった際の応急処置について重みを置きたい。

ディザスタリカバリ（Disaster Recovery）

インフラ故障時にアベイラビリティ指標が重要な指標である以外に、RPOとRTOこの二つの指標は事故処理の迅速性と応急措置の妥当性をうまく測ってくれる。
RTO　: Recovery Time Objective, “how long can we afford for the system to be down?”　すなわち我々が容認できるシステムシャットダウンの時間であり、故障発生してから回復までの予測時間でもある。この指標は業務指標だけではなくビジネスの指標でもあり、会社の経営層が定める会社として容認できる業務シャットダウンの時間である。
RPO　: Recovery Point Objective, “how much data are we willing to lose?”　これはデータの差異（あるいはロス）を測る指標で、どれくらいの時間内にデータの差異を回復するかを測る。この指標はデータのバックアップと同期化仕組と直接関連していて、異なるデータのバックアップと同期化の戦略によってRPO目標で甚大な差異が出てくる。
以下の図は災害発生時に、RPOとRTOの関係を示す。

災害回復の難易度と操作手段はインフラのアーキテクチャにより決まる。従いRTOとRPOの目標の設定もインフラのアーキテクチャにより決まり、異なるインフラアーキテクチャでDRの戦略と操作方法が決まってくる。
技術要素以外に、RTOとRPOの目標設定はインフラへの投資と強い相関性を持っており、RTOとRPOの目標設定の時間が短縮されればされるほど投下必要なコストも著しく増加する。ですので、RTOとRPOの目標を設定する時は、会社全体の経営からバランスを考慮すべきである。

マルチクラウドアーキテクチャ

ネットスターズは同時にAWSとGCPこの二つのパブリッククラウドサービスを使っている。これによりシングルクラウドでパブリッククラウドそのものがダウンする際StarPayのサービスが止まる事象を避けてくれる。また、ペイメント業務とインフラで重大な変更を行う際に、安全且つ信頼できる対応手段も提供してくれる。
以下の図はネットスターズのマルチクラウドのインフラアーキテクチャである：

マルチクラウドアーキテクチャは高い安定性と柔軟性を持っており、AWSまたはGCPが故障時に、StarPayペイメントサービスは中断しない一方、回復時も柔軟な対応ができる。
全体のアーキテクチャーは前から後ろまで四つの部分に纏められる：
• DNS部分：AWSとGCPのトラフィック量を調整する役割で、比率・地域によりインターネットからマルチクラウドの入り口までのトラフィック量が設定できる。
• ネットワーク接続部分：各クラウドプロバイダーはみんな７層のパブリックネットワークロードバランサー（ALB）を持っている。これらがStarPayのネットワーク入口として、ALBを通じてトラフィックをイントラのOpenRestyサービスに接続し、更にOpenRestyからトラフィックをローカルのStarPayとリモートのStarPayに分配する。トラフィック量はOpenRestyを通じて柔軟な設定が可能になっている。
• コンピューティング部分：StarPayのサービスはコンテナ化されたマイクロサービスアーキテクチャを使っており、Kubernetesのクラスター上に配置されている。かつハイアベイラビリティの方式で配置し、相応な自動拡充縮小（HPA）機能と豊富なモニタリング機能を配置することにより、StarPayサービスの安定性と伸縮性を確保している。
• ストレージ部分：AWS側ではAWSのAurora MySQLサービスを使い、VPNを通じてリアルタイムでデータをGCP側のMySQL実例にコピーを残す。StarPayサービスの書き込みは全てAWS側のメインデータベースで行うが、読み取りは各々のローカルで実施する。

DR実施成果

上述通り、マルチクラウドのインフラアーキテクチャはStarPayサービスに対し良好な拡張性をもたらす一方、パブリッククラウドが故障時にも柔軟な応急措置が取れるようにしてくれている。
DRの構築とマルチクラウドの実現によりネットスターズで非常に良い実を結び、中でもアベイラビリティとコストこの二つ部分で成果が一番顕著である。
以下の図は2022年本文作成までのネットスターズのStarPayサービスのアベイラビリティの実績である：

この2022年のアベイラビリティ曲線から見れば、今年は非常に優秀な結果となっている。現在までアベイラビリティの実績値は99.999%であり、これはペイメント業界内でも非常に優秀な成績になっている。
今の仕組みで多くのメリットはある一方、一部のチャレンジは依然と存在し、故障になり得るリスクポイントも増加している。
• アーキテクチャーの煩雑性が高まり、技術と操作の難易度が上がり、これは対応チームにとって新たなチャレンジになる。
• マルチクラウドの構築により、毎月インフラ単体のコストが15％程度増加する。

纏め

ビジネスの急速な発展は技術ソリューションのエンドレスな最適化を促進していて、ソリューションはずっと進化し続けている。各々会社のDR策は自社の現状を鑑み、実現可能・検証可能・実施可能な仕組みにするべきであり、統一した「ルール」は存在しない。
我々のソリューションも課題は依然とありますので、業界の皆さんともぜひ忌憚のないコミュニケーションができれば幸甚です。

https://www.netstars.co.jp/contact/
上記urlより弊社へのコンタクトお待ちしております。

以上