アーカイブ動画

EKSの機能を活用し、金融システムに必要なセキュリティと信頼性を実現

株式会社野村総合研究所
金融基盤サービス部
エキスパートアーキテクト　高棹 大樹氏

最初に登壇したのは、日本で初めてKubestronautの称号を得た高棹大樹氏だ。Kubestronautとは、Kubernetesの5つの認定資格すべてを取得した者に贈られる称号であり、青いジャケットも併せて贈られる。この後に登壇するメンバーも称号を得ており、2人揃って青いジャケットでの登壇となった。

NRIに入社後は、オンプレ・クラウド問わずインフラエンジニアとして複数のエンタープライズシステムのインフラの設計・維持運用を担当した高棹氏。現在はAmazon Elastic Kubernetes Service（EKS）を用いた、金融機関に向けたマイクロサービス共通基盤のITインフラを担当しており、「金融システムをモダナイズするためのEKSノウハウ大全」とのテーマで講演を行った。

クラウドリフトは一巡し、クラウドネイティブなモダナイズ開発案件が増えていると近年の傾向を紹介した高棹氏。その上で金融システムは高度なセキュリティと信頼性が求められている、と語った。

Kubernetesに関するさまざまなサービスや機能を提供しているAWSでも、金融システムのベストプラクティス、リファレンスアーキテクチャ集を無償で公開している。

ただ、Amazon Elastic Container Service（ECS）の例はあるが、EKSを扱ったものはないと高棹氏は語る。そして、両サービスを比較した表を示した。

バージョンアップなどに要する運用コストはEKSの方が高くなりがちだが、それ以外の要素においては、「EKSの方がメリットが多く、実際の業務を通じてもこれらのメリットを享受するために、EKSを選択するケースが増えているように感じています」と、述べた。

そしてここからは、金融システムに求められる高度な要求をEKSで実現するための、さまざまなノウハウや具体的な機能、サービスを紹介していった。

まずはEKSを使った、前提となるインフラの構成要素を示した。ワーカーノードはFargateではなく、EC2（Amazon Elastic Compute Cloud）を採用した。

また、個別のNamespaceが割り当てられた複数のシステムがクラスタ上で稼働することを想定し、各システムのアプリケーションPodは、S3（Amazon Simple Storage Service ）バケットや、SQS（Amazon Simple Queue Service）などのAWSリソースにアクセスする構成とした。

続いては、高度なセキュリティを実現するための取り組みについて紹介した。EKSで高度なセキュリティを実現するためには、「クラスタを構成する各レイヤーで適切なセキュリティ対策を行っていくことが必要です」と、高棹氏は述べる。

具体的にはコンテナおよびコンテナ間、Namespace間やワーカーノード、EKSクラスタ全体のセキュリティ対策が必要となってくると述べ、それぞれのセキュリティ対策の詳細も解説した。

コンテナのセキュリティ対策では、Secretオブジェクト内に格納するという一般的な手法ではなく、外部のシークレットストアを活用。具体的にはAWS Secrets Managerを利用する。

なぜ、一般的な手法ではないのか。Secrets Store CSI Driverを使った外部ストアでのシークレット管理の手順や手法についても解説した。

コンテナ間のセキュリティ対策では、Podが各ワーカーノードに分散配置されている場合、Pod間の通信はワーカーノードを跨ぐことがある。

さらに、1つの処理を複数Podで連携しながら処理を行うマイクロサービスアーキテクチャにおいては、通信量が多くなるため、通信傍受されるリスクが高くなる。

そこで、Pod間の通信すべてを暗号化する。しかし、稼働Podのボリュームに伴い、暗号化に必要な鍵管理の手間が生じてしまう。そしてIstioなどのサービスメッシュを導入して対策する。

続いては、Namespace間のセキュリティ対策だ。今回のように単一クラスタ内に複数のシステムを稼働するような構成では、Kubernetes・AWSリソース両方が混在するため、他のシステムの管理者のアクセスなどによる、情報漏洩のリスクが高まると高棹氏は指摘する。

そこでKubernetesの機能、RBAC（Role Based Access Control）を使い、担当システムのNamespace内にある、Kubernetesリソースのみアクセスできるように設定する。

さらに、EKS Access Entryを使い、RBACとIAM（AWS Identity and Access Management）を紐づけることでIAMロールで管理者を認証し、KubernetesのRBACリソースで認可制御を行うアクセス制御が可能となる。

AWSリソースへのアクセス制限においては、Pod間の割り当てで利用するService AccountというKubernetesの機能を使う。

システムごとにService Accountを作成し、先ほど設定したIAMロールと、EKS Pod Identityという機能を使い、紐づける。その結果、各システム用のService Accountで認証し、IAMロールで許可認証を行うアクセス制御が可能となる。

ワーカーノードのセキュリティ対策では、怪しいコマンドの実行など、通常の振る舞いから逸脱した異常な行動を検出する振る舞い検知という仕組みを用いる。

同対策では、Amazon GuardDutyが対応。EKSランタイムモニタリング機能を用いることで検知可能となるが、「導入障壁が非常に低い一方で、未知の脅威に対して強いガードをかけることになります」と、費用対効果が優れていることを付け加えた。

EKSクラスタのセキュリティ対策では、監査ログのリアルタイムモニタリングを行う。なお、AWSリソースにおいてはAWSの機能であるCloudTrailで取得可能だが、EKSクラスタ内のKubernetesリソースは別に出力されるため、こちらもAWSのGuardDutyを用いることで、対応する。

続いては2つ目のテーマ、高度な信頼性を得るためのポイントについて、3つの観点から解説した。まずは、災害など有事の際にもシステムが継続利用できるよう、複数リージョンへリソースを分散配置する取り組みである。

複数のアベイラビリティゾーン（AZ）への分散配置についても解説した。ノードグループで各エージェントが作成したサブネットを複数指定すれば、複数エージェントでの分散配置は可能になる。

だが、特定のAZやワーカーノードに同一種類のPodが偏って起動する可能性があるため、「PodAntiaffinityを明示的に設定する必要があります」というノウハウを紹介した。

リリース時に問題があった際、即座に以前の状態に戻せる取り組みでは、Blue/Greenデプロイメントの運用方法を用いる。なおアプリケーションにおいては、「Argo Rolloutsを導入することで簡単に実現できます」と述べた。

一方、EKSクラスタではまずはALB（Application Load Balancer）を、Kubernetesのリソースとしてではなく、スタンドアローンで構築する。そして、エンドユーザーからの接続を受け入れるリスナールールを、現EKSクラスタのターゲットグループに紐づける。

さらに、稼働確認用のCookieやヘッダー付与で、EKSクラスタに振り分けるリスナールールも用意する。

このような環境を構築することで、エンドユーザーはEKSクラスタ上のアプリケーションに接続している状態でも、アプリ開発者はCookieやヘッダーを付与することで、EKSクラスタ上のアプリの稼働確認を行うことができるようになる。

3つ目はPodの安全停止設定についてだ。まず、ワーカーノードを停止する前に、ノード上で起動しているPodを他のワーカーノードに退避させる必要がある。退避の際には実際にはPodが停止し、その後、別のワーカーノードでPodが起動することで実現される。

ただサービスの仕様上、Podを停止前に該当Podを手動で切り離すことはできない。そこで、受け入れたリクエストの終了が完了する時間分、Podが停止を待つ設定を入れていく。高棹氏は具体的な設定方法も解説した。

まずはEKSクラスタを実運用する中で直面した問題と課題策について、具体的なクライアントやサービス名と共に紹介した。

IPアドレスが涸渇してPodが起動できなくなったトラブルである。

暫定対策として、Virtual Private Cloud（VPC）のCNIプラグインのパラメータのチューニングならびに、ワーカーノードに割り当てるサブネットを追加することで、一定期間を凌いだ。その後は可能な限り大きな単一のサブネットを作成し、その上でEKSクラスタを稼働させるという恒久的な対策も講じた。

続いては、EKSクラスタ内で稼働する全Podのメトリクス収集ならびに、アラート通知を実現するためのシステムにおいてのケースだ。アプリPodの増大により、Prometheus Server Podのメモリ容量が逼迫し、最終的にクラッシュした事例である。

当初はPrometheus Server Podのメモリ容量を増やすことで対応していたが、2023年11月に公開された、マネージドスクレイパーというサービスを導入することで、Prometheus Server Podの運用を行うことなく、アプリPodが増えても対処できるようになった。

その後も高棹氏は、AZに移動したPrometheus Server Podが起動しなかったトラブルならびに解決策、CoreDNSがパニックに陥ったトラブルとその解決策も紹介した。

また、AWSはEKS関連の新機能を精力的にリリースしているそうで「それらの機能を積極的に活用し、EKSの構成を継続的に進化させることが、さまざまな問題を解決していく上で重要だと思っています」。高棹氏はこのように述べ、セッションを締めた。

Kubernetes上でセキュアなAPIの認証認可を実現。API Gatewayの設計ノウハウ

株式会社野村総合研究所
プラットフォームサービス開発二部
シニアアーキテクト　勝村 友博氏

続いては、Kubestronautの資格を持つ勝村友博氏が登壇した。勝村氏はNRIに新卒で入社以降、ミドルレイヤーのエンジニアとして、主に金融業界のエンタープライズシステムのミドルウェアやAPI関連の開発業務に従事してきた。

現在はオープンソースのAPI Gateway開発にも携わっており、ミドルレイヤーのエンジニアならではの視点で、「金融システムのAPIをKubernetesで公開するまで」とのテーマで講演を行った。

勝村氏はまずマイクロサービスアーキテクチャが基本となるクラウドネイティブなシステムでは、APIの利用が必須のため、同技術を理解し使いこなせることが重要だと指摘。実際、ビジネスの変化が激しい現在では導入企業が増えており、誰もが知っているメジャーな企業やサービスも挙げた。

一方で、分割したサービスの増加により、サービス内部はもちろん外部との通信も増加するため、認証・認可をしっかりと行わないと権限を持っていないユーザーがデータを閲覧できてしまうなど、重大なインシデントにつながる、と語った。

また、物理サーバや仮想マシンに比べスケールが容易である。OSを共有しているため、リソースを効率的かつ素早く利用できる。

このような利便性から、アプリケーションの開発・実行環境として広まっているコンテナ技術。その中でもデファクトスタンダードなのがKubernetesであり、主要なクラウドベンダーが各種マネージドサービスを提供していることからも、NRIでも採用している、と述べた。

ここからは実際の金融機関のシステムにおける、Kubernetes上で稼働するアプリケーションのAPI Gateway領域について、詳しく解説した。まずは、マイクロサービスで構築されたシステムの概略を示した。

続いては、開発体制ならびに勝村氏が所属する、ミドルレイヤーチームの役割や立ち位置について述べた。アプリ・ミドル・基盤と大きくは3つのチームからなり、ミドルレイヤー担当チームの役割は、Kubernetes上で稼働する業務色の薄いアプリケーションの開発や、CI/CDの整備などである。

一般的なAPI Gatewayの役割や機能も紹介。その中から本セッションでは認証・認可について紹介した。

マイクロサービスにおけるAPIの認証・認可の方式は、スライドで示されたように大きく2つあり、各サービス内で認証・認可する方がセキュリティレベルは高いが、開発や学習コストが高いなどの特徴がある。

そこで勝村氏は、マイクロサービスを利用している世界的なサービスの状況を調べる。その結果、API Gateway内で認証・認可を行っていることが判明。同方式で進めることとした。

設計のポイントについても紹介された。認証フローはデファクトスタンダードである認可コードフローのOpenID Connectを採用。加えて、金融レベルの高いセキュリティを実現するためのAPI規格である、Financial-grade API (FAPI)も対応することとした。

API Gatewayにはクライアントからの業務APIへのリクエストだけでなく、他のシステムからも、例えば公開鍵を要求するJWKs（JSON Web Key Set）リクエストなども届く。

そこでリクエストを種別し、それぞれのパターンに対してどのような処理をどんな順番で適応していくかを整理。「地道な整理になりますが、このようなパターン整理はかなり重要だと考えています」と、同取り組みの意義を述べた。

鍵管理についてはKubernetesのSecretとして登録し、API Gatewayにファイルマウントする方式を採用した。

採用の理由の1つが、Blue/Greenのアプリケーションデプロイ方式を採用していたからであるが、API Gatewayだけの鍵を更新してもバックエンド側のアプリケーション鍵は更新されないため、同処理を実行するためのSDKを開発し、全チームで共有することで対応した。

API管理においては複数のクライアントが存在し、それぞれ呼び出し可能なAPIが異なることなどから管理テーブルを作成し、それぞれ参照する設計とした。

「挙げるとキリがない」と、勝村氏は今回の取り組みの苦労もいくつか紹介した。例えば、デバッグのためにビルドとデプロイを繰り返す必要があり時間を要し、非効率となっていたことだ。

ビルドとデプロイの工程を変えることができなかったため、デバック用ブランチのみ自動テストをスキップさせることで対応したが、「ワークアラウンド的な回避方法だと思っています。デバッグ用のビルドやAPI Gatewayにデバッグしやすい仕組みを整備しておけば良かったと考えています」と、述べた。

勝村氏は改めてプロジェクトへの取り組みを振り返り、苦労ポイントの振り返りにもつながるが、「若いうちから苦労や失敗といった経験をすることで、次のプロジェクトに活かしておくことが必要だと思っています」と、語った。

また、Kubestronautとして得た知識も、紹介したプロジェクトのような大規模エンタープライズシステムの開発や運用でも役立つとも述べた。

ここからは一転、NRIが取り組んでいるOSSの活用、関連する技術サービスなどについて紹介した。

まずは、取り組みに至る背景を紹介した。2人の登壇内容からも分かるように、クラウドネイティブなシステムでは複数のOSSを活用することがスタンダードになってきており、ベンダーロックを好まないクライアントの増加もその一因だと、勝村氏は語る。

一方で、金融システムに限ったことではないが、大規模なエンタープライズシステムでは障害時対策としてサポート体制の構築は必須である。だが、OSSはオフィシャルなサポート体制が整っていないこともある。

このような状況を鑑みNRIでは、OSSを使用したシステムの構築から導入、さらには実装後の運用時に発生した障害の調査や対応など、OSSを利用したシステム開発を一気通貫でサポートするサービスを展開している。

2006年から取り組んでいる「OpenStandia」であり、今回紹介したKubernetesはもちろん、API Gateway領域ではKong Gatewayなど、対象となるOSSは130以上に上る。

さらにNRIでは、これらのOSSに関する知見を活用すべくAILERON GatewayというオープンソースのAPI Gatewayを自分たちで開発している。AILERON Gatewayの開発はそもそも、入社3年目のエンジニアの希望が実現したもので、「NRIには若手でもチャレンジできる風土があると考えています」と、勝村氏は語った。

現在はまだ基本的な機能を備えたレベルだそうだが、勝村氏のような認証・認可の専門家が開発に携わることで、他のAPI Gatewayとの差別化を図っており、現に続々と認証フローの規格に対応していることも紹介した。

一方で、ドキュメントが不足しているとの課題もあることから、聴講者に向けてコントリビュートをお願いしますとのメッセージを投げかけ、セッションを締めた。

【パネルディスカッション】Kubernetesは幅広い知識や他部門との連携が必要

ここからはKubernetesに関する2つのテーマについて、登壇者2名が意見を出し合った。要約して紹介する。

●ミドル・インフラレイヤーの境界線

高棹：交差する部分はありますが、役割分担やどこまで責任を担うかといった観点で、線引きする必要があると考えています。具体的には、どのコンテナを担当するのか、マニフェストも含めて管理しています。

ただし、Kubernetesのマニフェストは機能・非機能要件含め設定する部分がたくさんあり、耐障害性を保つためのものもあります。

そのような機能設定においては、インフラレイヤーからインプットしてもらう働きかけが必要だと考えていて、雛形的なマニフェストを作成し、連携したりコラボレーションしたりするような、お互いの歩み寄りが一番必要だと思っています。

勝村：管理しているマニフェストは、アプリ・基盤チームで完全に分かれていて、アプリチームしか見られないマニフェストなどもあります。一方で、Kubernetesは基盤からアプリまでのレイヤーがあることから、特にIngressやSecretといったリソースに関しては、グレーな部分もあると考えています。

例えば、Secretに関するマニフェストは基盤チームが管理するけれど、利用するのはアプリチームですよね。そのため設定は基盤チームで行いますが、アプリチームがマニフェストを書くようなことはあり、このようにチームごとはもちろん、プロジェクトごとに自由に対応しているようなイメージです。

──管理の主体はインフラチームで、実際の操作はアプリチームが行うと。仕事の受け渡しなどはどのように行っているのでしょうか？

高棹：チャットツールを使ってファイルの共有を行うなど、コミュニケーションを多く行っています。

──このような機能要件を実現したいなど、アプリチームからの相談などはあるのでしょうか？

勝村：例えばIngressでは、アプリケーション側が望むルーティングがあり、そのような要望を元に、アプリ・ミドル側でルールを決め、決まったルールをインフラチームに依頼してもらうような、逆の流れもあります。

──厳しい要求などもあるのではないでしょうか？

高棹：アプリチームというよりもお客様から、例えばDRの切り替えを素早く自動で行いたいといったニーズなどはあり、実際に応対しています。KubernetesはAPIを叩いて自動化することが基本です。

そのためインフラ側にも、オンプレ時代にはそれほど必要ではなかった幅広い知識が求められるようになってきたと感じています。

──意見が合わなかったり、衝突するようなこともあるのではないでしょうか？

勝村：思想的な観点でぶつかることはありません。一方で、技術的に難しいテーマに関しては日々のミーティングで摺合せながら、落とし所を見つけていきます。

高棹：なぜ、そのような機能を実現したいのか。その背景や、別の案で実現できないかどうかを検討します。このような環境を実現していくためにも、日々のコミュニケーションを通じ他のチームが何を求めているのか、知識も含めて知ることが必要だと考えています。

そのためNRIではプロジェクトのキックオフ時に、飲み会的なパーティーを催し、メンバー同士のコミュニケーションを深めています。そしてプロジェクト終了後にももちろん、打ち上げと称した飲み会を実施します（笑）。

●組織全体の技術力を向上させる取り組み

高棹：私と勝村さんでクラウドネイティブの勉強会を隔週で実施しています。勉強会では社内事例の共有や知識の土台づくりなどを行っています。またチーム内部でもKubernetesの勉強会を行っていて、各種資格の取得は技術力をつけるために有用なので、すすめたりもしています。

勝村：資格取得は時間の無駄だとの考えもありますが、セッションでも話したように、私の場合は資格取得で得た知識が実際の現場で一番発揮された。そのように捉えています。

高棹：Kubernetesの試験はただ知識を覚えるだけのものではなく、障害対応をどのように行っていくかなど、実際に手を動かす実技試験です。そのため実業務でも有用なのだと思います。

──テスト対策はどのように行っているのでしょうか？

高棹：Webで公開されているマニュアルを読んで、専用のオンラインサイトもあるので活用しました。

勝村：私もオンラインサイトメインで、毎日少しずつですがとにかくKubernetesに触れる、手を動かすことを意識し、仕組みも含めて深く学んでいきました。

【Q＆A】参加者から寄せられた質問に登壇者が回答

パネルディスカッション終了後は、Q＆Aタイムも設けられた。抜粋して紹介する。

Q．ログのリアルタイムモニタリングはコストがかかるのではないか？

高棹：たしかにコンテナが増えるにつれ、保管コストは増大していきます。そこで、長期保管の場合はS3に、中でもGlacierを選択するなど、保管先を工夫しています。

Q．AWSのような閉じたネットワーク内であれば、マイクロサービスにおけるコンテナ間の通信を暗号化するといったセキュリティ対策は必要ないのではないか？

高棹：状況によるかと思います。例えば、1つの環境でも異なるベンダーが関係している場合は、他のベンダーが情報を見る可能性があるからです。

Q．振る舞い検知にGuardDutyを採用した決め手は？

高棹：AWSの機能で行えるため、追加のソフトウェアを入れる必要がないことが大きいですし、それこそがAWSのメリットでもあると思っています。

Q．認定資格のための学習教材について知りたい

勝村：Killercodaというオンライン環境で使える教材があるのですが、自分は8割方この教材で学習しました。具体的には、3回繰り返してコマンドを覚えていなかったり、理解度の浅いものを洗い出し、再学習するといった流れです。

高棹： Udemyの講座もKillercodaと同じように、コマンドを打ちながら学習できるのでおすすめです。また初学者向けではLinux FoundationがKubernetes入門というサイトを無料で配布しているので、こちらもおすすめです。

参照：https://killercoda.com/
https://training.linuxfoundation.org/ja/training/introduction-to-kubernetes-lfs158-jp/

Q．AILERON Gatewayを自社開発した理由を改めて語ってほしい

勝村：エンタープライズの色々なシステムを構築していると、OSSでは機能面で不足だと感じるところがありました。ただ、コミュニティが活発なOSSでないと機能追加を行うのは難しいので、であれば自分たちでハンドリングできるOSSを開発しよう。このような思いもありました。

株式会社野村総合研究所
https://www.nri.com/jp/

株式会社野村総合研究所の採用情報
https://career.nri.co.jp/