2024.01.18
キャッシュレス化が進む現在、FinTechサービスは世の中に普及しつつあります。なかでもQR決済やインターネットバンキングは人々の生活に身近なサービスとなってきました。しかし、身近なものになったからこそ、アクセス障害が発生した際の影響も大きくなってしまいます。
本記事では、Fintechサービスのなかでも広がりを見せるQR決済・インターネットバンキングに注目し、アクセス障害を防ぐ品質向上策を紹介します。サービスの開発から運用までの工程ごとに、品質を担保するためのポイントを解説していきます。
頻発するアクセス障害と影響の大きさ
FinTechサービスのキャンペーンを目にしたことがある方は多いのではないでしょうか。QR決済はポイント還元率が高く設定されることもあるため、利用者が殺到しアクセス障害につながったケースがいくつかあります。
とくにQR決済・インターネットバンキングはユーザーである消費者の経済活動を支えるサービスです。そのため、障害が発生してしまうと経済活動の停止・混乱を招く可能性があります。
サービス提供者は、ユーザー以上に深刻な打撃を受けます。アクセス障害期間中は、取引ができないために手数料を得られず、売り上げがゼロになってしまいます。また、復旧後にもさまざまな対応が必要となります。ユーザーやシステム関係者への障害通知、影響範囲や障害中に発生した取引の調査といった緊急対応に加え、その後も原因の調査および再発防止策の策定などを行わなければなりません。さらにはシステムの改修が必要となるケースもあります。
このように、一度アクセス障害が発生してしまうと、ユーザー・サービス提供者ともに大きな影響を与えてしまうほか、サービスの信頼を失ってしまう恐れもあるのです。そのため、未然にアクセス障害を防ぐ取り組みが求められるのです。
アクセス障害が発生する原因はさまざまですが、例として、
- 要件定義におけるアクセス集中の過少想定
- 想定するアクセス数を処理できないシステム設計
- 性能問題を検出できないテスト
- 障害の兆候に気付けない運用・監視体制
などが挙げられます。
これらを回避するために、エンジニアは具体的にどのような策をとる必要があるのでしょうか。
アクセス障害を防ぐ、工程ごとの品質向上策
前述のとおり、アクセス障害が発生する原因はさまざまです。そのため考え得る原因すべてを潰していくことは現実的ではありません。アクセス障害を未然に防ぐための品質は、通常の品質向上の考え方と同じく、各工程で作り込みます。要件定義工程だけで品質は決まりませんし、テスト工程になって要件定義や設計からやり直しとなると、手戻りにより多くの時間とコストがかかってしまいます。
そのため、各工程で可能な限りの品質を確保して、次工程に進みましょう。ここでは「要件定義」、「設計・実装」、「テスト」、「運用」の４つの工程について見ていきましょう。
要件定義で目指すべき性能要件と大まかな達成手段を定める
要件定義工程にて扱う要件は、「システムで何がしたいのか」を決める機能要件、それに対して「システムを安心して快適に使う」ためにセキュリティ・性能要件などを決める非機能要件に大別できます。
アクセス障害を防ぐためには、後者の非機能要件を検討する際に、性能・拡張性（利用者が増えてもダウンしないか、後から性能を上げられるか）や可用性（いつ何があっても使えるか）についての適切な指標を設定する必要があります。なぜならここで設定された指標を目指して、後の全工程が進められるからです。
これらを数値で示す代表的かつ重要な指標として、レスポンスタイム、スループット、稼働率の３つを紹介します。
レスポンスタイム
レスポンスタイムは、処理を要求してから応答を受け取るまでに要した時間のことで、ネットワークからアプリケーションの処理時間までを考慮して指標を設定します。レスポンスタイムの指標は、通常時とピーク時を分けて決めることもあります。
スループット
スループットは単位時間あたりの処理量のことで、1秒あたりの処理量を示すTPS（Transactions Per Second）という単位がよく使われます。目標とするユーザー数と、ユーザーあたりの利用頻度、キャンペーンのピーク時に見込まれる処理量も考慮して指標を設定するとよいでしょう。
稼働率
稼働率は、全時間に対してサービスが利用可能である時間をパーセンテージ(%)で表した指標です。障害による停止時間だけでなく定期的なメンテナンスによる停止時間も含めて割り出し、設定するようにしましょう。
要件定義工程においては、これらの指標を満たすようなシステム構成を検討したうえで、開発、運用のコストを見積もりましょう。
予算内に収めることも重要ですが、目指す性能要件を達成するためにどうしても予算が足りない場合は、追加の予算確保、もしくは開発の中止を検討しましょう。後の工程になるほど追加予算の確保が難しくなるうえ、リリース後に想定した性能が達成できないことが判明した場合、サービス廃止に追い込まれる可能性もあります。
また、アクセス集中に備える拡張性を担保するために、サーバーの追加（スケールアウト）やサーバーの増強（スケールアップ）が可能なシステムの構成が望ましいです。後手の対応とならないように、将来的にスループット（アクセス数）が増えた際の対応も、要件定義工程で検討しておくようにしましょう。
AWSなどのクラウド基盤に仮想サーバーを構築すればオートスケールという技術を利用できます。サーバーやネットワークの負荷に応じて自動的にスケールアウトされるため、アクセス障害を防ぐだけでなく通常運用時のコストを抑えることも可能です。
このように、要件定義工程では、システムが発揮すべき性能と大まかな実現への道筋を立て、発生し得るアクセス数やアクセス集中時の対応策を想定しておくことが重要です。
設計・実装工程で性能要件を達成できるシステムを作る
設計工程では非機能要件で定義した各指標を満たせるように設計しなければなりません。
設計工程を「インフラ、ミドルウェア、データベース、アプリケーション」の４つに分類し、アクセス障害を防ぐために注意すべきポイントを見ていきましょう（データベースは本来ミドルウェアに含まれますが、注意すべき点が多いため、ミドルウェアとは別に解説しています）。
設計工程：インフラ
ネットワークやサーバーといったインフラの設計時にまず注意すべきことは、想定するトラフィックをさばけるかということです。設計時のトラフィック想定が甘いために、サーバーのメモリが足りず処理できない、回線の帯域幅が細く通信が遅くなってしまう、といった事態はアクセス障害の原因となるため避けなければなりません。
設計工程：ミドルウェア
次にWEBサーバーやアプリケーションサーバーといったミドルウェアで気をつけるべきことは、同時接続数やタイムアウト値などの設定です。
想定したアクセス数を処理しつつも各ミドルウェアの性能限界を超えないように、緻密に設定値を決めなければなりません。システムの全体を俯瞰できるような設計書を作成し、各所の設定値が想定するトランザクション数をさばけるか確認できるようにしましょう。
設計工程：ミドルウェア（データベース）
また、ミドルウェアのうち、とくにデータベースにおいては注意すべき点が多くあります。アクセス障害を起こす原因を作らないよう、慎重に対応するようにしましょう。
まず、データベースの設計段階ではパフォーマンスを意識したテーブル設計、インデックスの設定を行いましょう。
また長期の運用を想定する場合は、データ量増加による影響、一塊のデータが記憶媒体にバラバラに記録される断片化、統計情報が古くなることにも留意したデータベースの設計が必要です。
そして見落としがちですが、オフラインのバッチ処理の実行時刻は、オンラインのピークを避けて設定することも忘れないようにしましょう（オンラインと同一のデータベースを利用している場合）。これらの時間帯が被ると、データベースの性能が限界に達し、アクセス障害につながる恐れがあります。
設計工程：アプリケーション
最後にアプリケーションに関して、メモリ管理が性能問題を引き起こすことが多いため、設計・実装時には注意しましょう。
通常、アプリケーションではガベージコレクションというメモリ管理が機能していますが、自動だからと任せていると正常に動作しないこともあります。プログラムの設計によっては無駄にメモリを食い潰してしまうことさえあるので、メモリを無駄に使う設計・メモリを解放しないような設計は避けましょう。
要件定義の内容をふまえ、本番運用を想定した設計・実装ができれば、次の工程、テストに移ります。
テスト工程で性能要件を達成できているか確認する
要件に沿って設計・実装が完了したら、性能要件を満たせているか確認するためにテストを実施しましょう。アクセス障害を回避するためには、以下３つの負荷テストが重要となります。
- レスポンスタイムを測る「性能テスト」
- 高負荷で、長期間の運用を想定した「耐久テスト」
- 性能要件以上の大量アクセス時の挙動を確認する「限界テスト」
性能テスト
性能テストでは、各画面やAPIにおいて処理に時間がかかるものがないかを確認します。処理に時間がかかりすぎると、その間コネクションやサーバーリソースを占有してしまうため、アクセス障害につながる可能性があります。ここではプログラムやSQLの性能問題を発見することが多いです。
耐久テスト
耐久テストでは、長期間・高負荷での運用時においてもレスポンスタイム、スループットが達成できる耐久性を確認します。長期間運用時に発生しがちな、アプリケーションのメモリ不足や不要なコネクションの残存、またデータベースのデータ量増加による問題などはアクセス障害の原因となりうるため、これらを検知するテスト設計が重要となります。
限界テスト
限界テストでは、システムが耐えきれないほどの大量アクセスがあった際に、安全な挙動をするかを確認します。想定しないエラー画面が出ないか、取引不整合が発生しないかといった点に注意しましょう。
これらのテストにおいて重要な点は、可能な限り本番環境と同じ環境で行うことです。サーバーのスペック、各ミドルウェアの同時接続数などの設定、オフラインで稼働するバッチの影響など、環境に差があると性能問題を見落とすきっかけになってしまいます。
しかし、制約条件もあるなか、抜け漏れなく本番と同じ環境でテストするのは簡単ではありません。そのため、テストを実施する際は、できればリリース前の本番環境をそのまま使って行いましょう。
品質の門番であるテスト工程で、アクセス障害を引き起こしかねない箇所を検出・修正するようにしましょう。
運用工程でアクセス障害を予知し、対応する
無事リリースができても、それで終わりではありません。適切に運用することによって、アクセス障害の兆候検知や、発生時の迅速な対処が可能となります。
アクセス障害を防ぐための運用においては、監視設計と障害対応フローの策定が重要になります。まず監視設計としては、サーバーリソースやスループットを常時監視し、一定の水準まで達したらアラートを発砲するように仕込んでおきます。こうすることで、アクセス障害が起きる兆候を検知して事前に対処できます。
また障害対応フローとして、原因の特定から応急処置の方法、通知すべき関係者と通知内容など、障害時に踏むべき手順を策定し、まとめておきます。これにより、万が一アクセス障害が発生した際も影響を最小限にとどめ、適切な処置により二次災害の発生も防ぐことができます。
さらには障害訓練も行い、いつ何が起きても冷静迅速に対応できる準備をしておくことが望ましいです。
以上のように、運用工程では、アクセス障害の兆候を検知、また迅速に対応できるような体制を整えておくようにしましょう。
おわりに
QR決済やインターネットバンキングのサービス提供者としては、利用者の増加は喜ばしいことです。しかし、同時にアクセス障害のリスク・影響も大きくなることも忘れてはいけません。
アクセス障害が起きてからはじめて対応するような対応では、時すでに遅し、という事態にもなりかねません。アクセス障害を防ぐためには、要件定義の段階からの対策が必要となるのです。
また、すでにリリース済みのサービスに携わっているエンジニアの方も、ぜひ本記事のポイントをシステムに取り込めているか今一度確認してみるとよいでしょう。
