Kubernetes の冒険となったミッションクリティカルな患者ケアのユースケース

ダウンタイムは深刻な結果を招く可能性があります。

これらの言葉は、他のほとんどの業界よりも医療技術分野の企業に当てはまります。彼らの場合、「深刻な結果」には文字通り死が含まれる可能性があるからです。 私たちは最近、医療記録の保管をペンと紙から、世界中のいつでもどこでもアクセスできる安全なデジタルデータへと変革しようとしている企業の技術スタックを分析する機会を得ました。 これらのデータは、患者情報からケア指示、生物学的マーカー、医療分析、履歴記録、そして医療チーム間で共有されるその他すべてのものまで多岐にわたります。

同社は当初から、一見単純な疑問に答えようと努めてきました。 「介護従事者が簡単にリアルタイムでデータを記録できるようにするにはどうすればよいでしょうか？」 しかし、会社が成長するにつれて、規模を拡大し、データを常に利用できるようにする必要が生じ、その課題の解決はますます複雑になってきました。 ここでは、同社の技術の歩みがどのようにKubernetesとNGINX Ingress Controller の採用につながったかについて説明します。

技術スタックの概要

• OS – Linux
• コンテナ オーケストレーション – Microsoft Azure Kubernetes Service
• ネットワーキング – Kubernetes 、 NGINX PlusベースのNGINX Ingress コントローラー
• ソフトウェア開発言語/フレームワーク – .Net 
• 監視、可観測性、アラート – Prometheus
• 監視ダッシュボード – Grafana
• ロギング – Grafana Loki
• データベース – Azure SQL サービス
• アプリケーション サーバー – Azure App Service 、.Net
• メッセージングとストリーミング- Azure Event Hubs
• キャッシュ – Redis
• セキュリティ – NGINX App Protect
• 場所とインフラストラクチャ – 2 つのアベイラビリティゾーン、2 つの Kubernetes クラスター、15～20 個のノード、60～100 個のポッド 
• DevOps – Azure DevOps サービス

NGINX がアーキテクチャのどこに当てはまるかを見てみましょう。

紙の問題

定期的に患者の状態とケア情報を記録することは、医療従事者の中心的な義務です。 従来、患者の情報は紙に記録されていましたが、最近ではノートパソコンやタブレットに記録されるようになりました。 重大な欠点がいくつかあります。

• 医療従事者は 1 日に数十人の患者と接する可能性があるため、ケアを提供しながら詳細なメモを書くことは通常現実的ではありません。 その結果、労働者はシフトの終わりにメモを書くことになります。 その時点では、精神的および肉体的な疲労により、一般的なコメントのみを記録したくなることがあります。
• 作業員は患者の行動に関する詳細を記憶することにも頼らなければなりません。 不正確な情報があると、長期にわたって正しく一貫して記録されていれば、より大きな健康問題の診断に役立つパターンが隠れてしまう可能性があります。
• 紙の記録は、救急隊員、緊急治療室のスタッフ、保険会社などの他の組織はもちろん、単一の部門内の部門間でも簡単に共有できません。 ノートパソコンやタブレットが中央データストアやクラウドに接続されていない場合、状況はそれほど良くありません。

これらの課題に対処するため、同社は患者情報にアクセスし、投薬などの一般的なイベントを記録するためのショートカットを提供する、簡素化されたデータ記録システムを開発しました。 このアクセスと使いやすさにより、患者とのやり取りを発生時にリアルタイムで記録することが可能になります。

すべてのデータは同社が管理するクラウド システムに保存され、アプリは他の電子医療記録システムと統合され、入居者の行動を包括的かつ長期的に把握できるようになります。 これにより、介護者はより継続的なケアを提供できるようになり、安全な履歴記録が作成され、他の医療ソフトウェア システムと簡単に共有できるようになります。

医師やその他の専門家も、患者の入院や患者とのやり取りの際にこのプラットフォームを使用します。 患者の好みや個人的なニーズの記録が、どの施設にも保存されます。 これらを使用することで、患者が新しい環境で快適に過ごせるようになり、回復時間などの成果が向上します。

企業が患者データを保存しなければならない期間については、厳格な法的要件があります。 同社の開発者は、一般的なクラウド アプリケーションよりもはるかに優れた稼働時間 SLA を備えた非常に高い可用性を提供するソフトウェアを構築しました。 患者のファイルが読み込まれないという理由で救急車を待たせるのは選択肢にありません。

ガレージからクラウド、そしてKubernetesへの旅

多くのスタートアップ企業と同様に、同社は当初、共同創業者の自宅のサーバー上で最初の概念実証アプリケーションを実行することでコストを節約しました。 このアイデアが現実的であることが明らかになると、同社はデータセンターでハードウェアを管理するのではなく、インフラストラクチャをクラウドに移行しました。 Microsoft ショップなので、Azure を選択しました。 初期のアーキテクチャでは、Microsoft の IIS Web サーバーを実行するマネージド アプリケーション配信サービスである Azure App Service の従来の仮想マシン (VM) 上でアプリケーションを実行していました。 同社は、データの保存と取得のために、VM で管理アプリケーションとして実行される Microsoft の SQL Server を使用することを選択しました。

クラウドで数年間運用した後、会社は急速に成長し、スケーリングの苦痛を経験していました。 無限にスケーリングする必要があり、垂直方向ではなく水平方向にスケーリングする必要がありました。垂直方向は VM では遅くてコストがかかるためです。この要件により、コンテナ化と Kubernetes が自然な解決策として生まれました。 コンテナ化を支持するさらなる点は、同社の開発者が、停止のリスクを冒すことなく、アプリケーションとインフラストラクチャのアップデートを頻繁にリリースする必要があることです。 患者の記録が複数のタイムゾーンにまたがって絶えず追加されるため、顧客が直ちに不具合の影響を受けるリスクなしに、変更を本番環境にプッシュするための自然なダウンタイムは発生しません。

同社にとって論理的な出発点は、Microsoft のマネージド Kubernetes サービスである Azure Kubernetes Services (AKS) でした。 チームは Kubernetes のベスト プラクティスを調査し、AKS 上のノードとポッドで実行されているトラフィックとアプリケーションを効果的に管理するには、Kubernetes クラスターの前で実行されるIngress コントローラーが必要であることに気付きました。

トラフィックルーティングは柔軟かつ正確でなければならない

チームは AKS のデフォルトの Ingress コントローラーをテストしましたが、そのトラフィック ルーティング機能では、必要な方法で会社の顧客に更新を配信できないことがわかりました。 患者のケアに関しては、曖昧さや矛盾した情報が許されません。たとえば、同じ事象に対して、あるケアワーカーがオレンジ色のフラグを見て、別のケアワーカーが赤色のフラグを見るということは許されません。 したがって、特定の組織内のすべてのユーザーは同じバージョンのアプリを使用する必要があります。これは、アップグレードの際には大きな課題となります。 顧客を新しいバージョンに移行する自然なタイミングはないため、同社ではサーバーおよびネットワーク レベルでルールを使用して、さまざまな顧客をさまざまなアプリ バージョンにルーティングする方法が必要でした。

これを実現するために、同社は組織内のすべてのユーザーに対して同じバックエンド プラットフォームを実行し、組織内のインフラストラクチャ層でセグメンテーションによるマルチテナントを提供していません。 Kubernetes を使用すると、詳細なトラフィック ルールとともに、仮想ネットワーク ルートとブラウザー上の Cookie を使用してトラフィックを分割できます。 しかし、同社の技術チームは、AKS のデフォルトの Ingress コントローラーでは、必要に応じて顧客組織または個々のユーザーのレベルでルールが機能するのではなく、パーセンテージベースでのみトラフィックを分割できることを発見しました。

基本的な構成では、NGINX Open Source に基づく NGINX Ingress Controller にも同じ制限があるため、同社は、きめ細かいトラフィック制御をサポートするエンタープライズ グレードの製品である NGINX Plus に基づく、より高度な NGINX Ingress Controller に移行することを決定しました。 高度な柔軟性と制御性に基づく、Microsoft と Kubernetes コミュニティの NGINX Ingress Controller の推奨事項を見つけたことで、選択が固まりました。 この構成は、従来のトラフィック管理ではなく、企業のポッド管理のニーズをより適切にサポートし、ポッドが適切なゾーンで実行され、トラフィックがそれらのサービスにルーティングされることを保証します。 トラフィックが内部でルーティングされる場合もありますが、ほとんどのユースケースでは、監視上の理由から、NGINX Ingress Controller を介してルーティングされます。

ここにドラゴンがいる: 監視、可観測性、アプリケーションパフォーマンス

NGINX Ingress Controller を使用すると、技術チームは開発者とエンドユーザーのエクスペリエンスを完全に制御できます。 ユーザーがログインしてセッションを確立すると、すぐに新しいバージョンにルーティングされるか、古いバージョンに戻される可能性があります。 パッチは組織内のすべてのユーザーに同時に、ほぼ瞬時にプッシュできます。 このソフトウェアは、クラウド プラットフォーム全体の DNS 伝播やネットワークの更新に依存しません。

NGINX Ingress Controller は、きめ細やかで継続的な監視という同社の要件も満たしています。 ヘルスケアにおいてはアプリケーションのパフォーマンスが極めて重要です。 遅延やダウンタイムは、特に生死に関わる状況では、臨床ケアの成功を妨げる可能性があります。 Kubernetes への移行後、企業が気付いていなかったダウンタイムが顧客から報告され始めました。 同社はすぐに問題の原因を発見した。 Azure App Service はサンプル データに依存します。 サンプリングは平均値や大まかな傾向を把握するには適していますが、拒否されたリクエストや不足しているリソースなどはまったく把握できません。 また、介護者がチェックインして患者のデータを記録するときに通常 30 分ごとに発生する使用量の急増も表示されません。 同社は、レイテンシ、エラーの原因、不正なリクエスト、利用できないサービスについて、不完全な情報しか得られませんでした。

問題はそれだけでは終わりませんでした。 デフォルトでは、Azure App Service は保存されたデータを 1 か月間のみ保存します。これは、多くの国で法律で義務付けられている数十年に遠く及びません。  より長期間保存するために必要なデータ ストアを拡張するには、法外なコストがかかりました。 さらに、Azure ソリューションでは Kubernetes ネットワーク スタックの内部を見ることができません。 NGINX Ingress Controller は、レイヤー 4 およびレイヤー 7 のトラフィックを処理する際に、インフラストラクチャとアプリケーションの両方のパラメータを監視できます。

同社は、パフォーマンスの監視と観測性を確保するために、Grafana 視覚化エンジンとダッシュボードに接続された Prometheus 時系列データベースを選択しました。 Prometheus および Grafana との統合は NGINX データおよびコントロール プレーンに事前に組み込まれているため、技術チームは、すべてのトラフィックを Prometheus サーバーおよび Grafana サーバーに誘導するために、わずかな構成変更のみを行う必要がありました。 この情報は Grafana Loki ログ データベースにもルーティングされ、ログの分析が容易になり、ソフトウェア チームが長期にわたってデータをより細かく制御できるようになりました。 

この構成は、トラブルシューティングやバグの修正のために非常に頻繁かつ大量のデータ サンプリングを必要とするインシデントに対しても将来的に対応します。 こうしたタイプのインシデントに対処するには、ほとんどの大手クラウド企業が提供するアプリケーション監視システムではコストがかかる可能性がありますが、このユースケースでは Prometheus、Grafana、Loki のコストとオーバーヘッドは最小限です。 これら 3 つはいずれも安定したオープン ソース製品であり、通常は初期調整後のパッチ適用以外はほとんど必要ありません。

コースを守り続ける: 高可用性とセキュリティに重点を置く

同社は常に、最も機密性の高いデータの 1 つを保護するセキュリティと、必要なときにいつでもアプリを利用できるようにするための高可用性という 2 つのことに重点を置いてきました。 Kubernetes への移行では、両方の能力を強化するためにいくつかの変更を加えました。

最高の可用性を実現するために、技術チームは、単一障害点のない完全な冗長性を実現するアクティブ/アクティブ、マルチゾーン、マルチジオ分散インフラストラクチャ設計を導入しています。 チームは、2 つの異なる地域にあるデュアル Kubernetes クラスターを使用して、N+2 アクティブ/アクティブ インフラストラクチャを維持しています。 各地域内で、ソフトウェアは複数のデータセンターにまたがってダウンタイムのリスクを軽減し、インフラストラクチャのどのレイヤーでも障害が発生した場合にカバーを提供します。 アフィニティ ルールとアンチアフィニティ ルールを使用すると、ユーザーとトラフィックを稼働中のポッドに即座に再ルーティングして、サービスの中断を防ぐことができます。 

セキュリティのため、チームは不正なリクエストや悪意のある行為者から保護するためにWeb アプリケーション ファイアウォール(WAF) を導入しています。 OWASP Top 10に対する保護は、ほとんどの WAF によって提供される最低限のものです。 チームはアプリを作成する際に、ネイティブの Azure WAF や ModSecurity など、さまざまな WAF を調査しました。 最終的に、チームはインライン WAF と分散型サービス拒否(DDoS) 保護を備えた NGINX App Protect を選択しました。

NGINX App Protect の大きな利点は、NGINX Ingress Controller との共存です。これにより、冗長ポイントが排除され、レイテンシが短縮されます。 その他の WAF は Kubernetes 環境の外部に配置する必要があり、レイテンシとコストの増加につながります。 たとえごくわずかな遅延（たとえば、リクエストごとに 1 ミリ秒の追加遅延）であっても、時間が経つにつれてすぐに蓄積されていきます。

サプライズサイドクエスト: 開発者のダウンタイムなし

同社はアプリケーションとネットワーク インフラストラクチャの大部分を AKS に移行し、開発者エクスペリエンス (DevEx) も大幅に向上しました。 現在では、顧客が問題に気付く前に、開発者が問題を発見することがほとんどです。 切り替え以来、エラーに関するサポートコールの量が約 80% 減少しました。

同社のセキュリティおよびアプリケーション パフォーマンス チームには、詳細な Grafana ダッシュボードと統合アラートが用意されており、複数のシステムをチェックしたり、さまざまなプロセスからの警告テキストや呼び出しのトリガーを実装したりする必要がなくなりました。 開発チームと DevOps チームは、コードとインフラストラクチャの更新を毎日、または 1 日に複数回出荷し、非常に細かいブルーグリーン パターンを使用できるようになりました。 以前は、週に 1 回か 2 回アップデートを配布しており、使用率の低い時間帯に合わせて配布する必要があり、ストレスの多い作業でした。 現在では、コードは準備が整うと出荷され、開発者はアプリケーションの動作を観察することでその影響を直接監視できます。

結果は全体的に良好で、ソフトウェア開発速度の向上、開発者の士気の向上、そしてより多くの命が救われました。