ＤＴＳの重要ソリューションの一つ『AMLion』をEKS化—Argo Rolloutsによる高可用デプロイと「技術の内製化」を実現した伴走型SRE支援 | 活用事例

マネーロンダリング対策パッケージは、海外製品のシェアが大きい状況ですが、国内製品にも優位性はあると考えており、ＤＴＳでもパッケージソフト「AMLion(アムリオン)」を展開しています。

顧客管理、制裁リスト照合、取引モニタリングが一つのパッケージで統合されている点や、漢字やカナの名前と英字の制裁リストと照合できる点など高度なあいまい照合、そして顧客要望にスピーディに対応できる高い柔軟性に強みを持たせています。

約８年ほど前に何かソリューションを作りたいという想いで、海外も含めて様々なセミナーやイベントへ視察に行った中で、AML関連のソリューションがこれから必要となっていくのではないかと考え、AMLionの開発企画を立ち上げました。

AML業界の中では後発となるので、AMLionの強みを強化していくことに日々取り組んでいます。

はい。弊社のサイトをご覧いただくと、AMLion以外にもGeminiotやPasteriot.miなど、特に製造業向けのソリューションが数多くあります。また、Walk in homeのような3D設計図を実際の3Dで見せたり、バーチャルで体験できるサービス等もオファリング分野と位置づけており、更なるサービスの向上を目指しております。

基本的な仕組みとして、オンラインでユーザーが使う部分、バッチシステム、そして最近できたAPI機能があります。今までは、オンプレミスやIaaSに導入するケースが多かったのですが、最近コンテナ上で動作するサービスを提供し始めました。つまり、従来はPC上で動いていたものを、最近コンテナ化したという状況です。

これまで数々のお客様システムの開発で培ってきた金融業務知識を活用した新しいビジネスとして、この金融犯罪対策ソリューションをさらに盛り上げていこうという位置付けです。

ビジネス上の課題として、AMLパッケージ展開が後発であることが挙げられます。他社は早めに動いており、導入実績が豊富なところに対して、導入実績が少ないＤＴＳが戦うのは厳しい状況でした。そこで、ＤＴＳ自体が金融業界のシステム開発において、長い間プライムで携わった実績があるという点や、技術面、例えばコンテナ技術にもAMLionが対応している点などをアピールポイントとしました。他社製品ではコンテナに対応していないこともあり、「コンテナにも対応できますか」という問いに対して、即座に「できます」と言えたことも大きな強みになりました。

システム面での課題としては、最近APIを利用したリアルタイムモニタリングが増えてきたことです。最近のAML業務では、リアルタイムでチェックを行い、レスポンスを返すことが求められています。そうなると、性能や可用性、つまりシステムを落とさずに高いパフォーマンスで動き続けられるかが課題として上がってきており、ここをどう強化していくかがシステム面での課題だと考えています。

提案先のユーザ様から「EKSを利用したい」という強いご要望があり 、外部コンサルも含めてどう対応していくか検討しようとなりました。

そこで、弊社の AWS 部門に（EKSに強いパートナーがいないか）相談したところ、「スリーシェイクさんがその領域に強い」ということを聞きました 。それがスタートです。

スリーシェイクさんに決めた判断基準は、技術的に精通していることに加え、大澤さん（スリーシェイク営業）が「ＤＴＳ 内にナレッジを残す」という形で支援していただけるという点が、私としては一番重要なポイントでした。

参画当初は、ＤＴＳ様から技術的なご質問にお答えする救援的な対応から始まりました。その中で状況や要望をヒアリングするうちに、開発者が自由に操作できるサンドボックス環境の必要性が明確になり、その環境立ち上げのご支援もさせていただくことになりました。

お客様側の環境には、デプロイ先となるEKS環境は既に存在していましたが、プロジェクトの都合上、開発当初は自由にアクセスできないという背景があり、質問対応に加えて、CDパイプラインを含むサンドボックス環境の構築を行ないました。

提供サービスの概要や、EKS環境にデプロイされるという状況、Kubernetesに関する知見がまだ限定的というお話を伺う中で、私たちのミッションは、自分たちの知見を元に環境を構築するだけではなく、それと並行して、ＤＴＳ様が今後EKSの環境に対して継続的に改善を進められるように、知識やスキルを移譲して実装できる状態を作り出すことが必要だと考えました。

その第一歩として、ヒアリングした情報を基に、お客様環境を正確に再現したサンドボックス環境を用意して、実際にデプロイする際の技術的な障壁を取り除くと共に、実際に手を動かして試してみる環境の整備に注力しました。

主に3つのアプローチで支援させていただきました。

1つ目は、これまでお話させて頂いているサンドボックス環境の提供です。環境をIaCで整備することによって、いつでも同じ環境を再現できるというIaCのメリットや、コード自体が環境の仕様書となるためナレッジ移管が可能になるという点を意識しました。また、最終的にはお客様環境のEKSにデプロイするということで、同じ資源とデプロイ形式で実行できる点を意識しておりました。

2つ目は、具体的な知識の移管方法です。定例の場をいただいていましたので、そこでお客様が利用されるArgo CDなどのツールについて、使用機能やサンプルなどをまとめたドキュメントを準備させていただき、説明とデモをさせていただきました。ＤＴＳ様に実際に触っていただいた後に出てきた質問に、その場で回答するなどのサポートを実施しました。

3つ目は、デプロイ方式の整理です。金融機関向けサービスとして、信頼性高くリリース作業を行うことを目的に、ブルーグリーンデプロイを実現したいという要望がありました。対象の環境がArgo CDとLinkerdを利用することは決まっていましたので、これらの技術をどう組み合わせて要望を実現できるかという点を支援させていただきました。

選定した構成の強みとしては、Argo CDとArgo Rolloutsで新旧両方のバージョンを並行してデプロイして、Linkerdでユーザのトラフィックを制御するというものです。これによって、ユーザがアクセスする前に本番環境での動作検証を可能とすると共に、動作確認中に問題が発生しても、即座にトラフィックを元のバージョンに戻すことができるので、サービスへの影響を最小限にできるというメリットがあります。

こちらについても、ドキュメントや実際の定義・設定をご説明させていただいて、サンドボックス環境でデモをさせていただきました。ＤＴＳ様が安全なリリースプロセスを具体的にイメージしていただけるよう注力しました。

そうですね。

元々環境があって決まっているものと、そうでないものがあります。3つ目のブルーグリーンデプロイの実現に向けたArgo Rolloutsの選定に関しては、スリーシェイク側から提案を行い、導入を進めさせていただきました。

Argo Rolloutsを選定した主な理由は3つあります。1つ目は、ArgoCDとの親和性が非常に高く、デプロイフローにスムーズに組み込まれる点です。2つ目は、独自のスクリプトではなく、お客様が将来にわたってメンテナンスしやすい標準的な方法を採用できる点です。3つ目は、Kubernetesの標準的なManifestで宣言的に管理・デプロイできるので、ポータビリティと構成の透明性が高い点です。

このArgo Rolloutsがデプロイの進行を管理し、Linkerdが実際のユーザーのトラフィックをブルーに分けるかグリーンに分けるかを制御する役割を担うことによって、お客様が求めていた信頼性とメンテナンス性を満たすリリースフローを確立することができたと思っています。

土台となる部分はKustomizeで作成させていただきました。実際のアプリケーションが複数ありますので、1つのアプリケーションを対応させていただいて、そちらを技術移譲も兼ねて、残りをＤＴＳ様の方で作成いただくというフローを取っておりました。

私は構築後のQ&Aフェーズから参加させていただき、本番環境で障害が発生した時に、障害調査や技術調査などを実施しました。

エンドユーザーが金融機関様ということもあり、サービス影響を非常にシビアに考えていました。特に障害発生時のお問い合わせに関しては、慎重に回答するよう心がけましたね。ドキュメントベースや有識者の資料だけではなく、ソースコードまでしっかり確認し、検証環境でちゃんと動作も見た上で、情報の正確性をなるべく担保しながらＤＴＳ様に回答するようにしていました。

増山さんが土台となる環境を作っていただいた後、私もQ&Aがメインとなるフェーズで参画しました。藤井さんが述べたように、エンドユーザーが金融機関様なので、例えばダウンタイムがどの程度許容されるか、システムがどの時間帯に利用されるのかといった前提情報を確認した上で、質問に回答するよう心がけました。

CI/CDやIaC、サービスメッシュなどの部分は、増山さんに動いていただいたこともあってスムーズに構築できましたが、やはり一番苦労した点は、いただいたものはあくまでサンプルなので、我々のパッケージに合わせてどんどん拡張して大きなものを作っていかないといけないというところです。一番苦労しましたし、時間がかかりましたし、難しかったです。

もちろん、色々とご協力いただきました。Kustomizeでできるだけ効率よく共通化するなど、増山さんにサポートいただきました。最終的にデプロイするアプリケーション数は数百に及ぶのですが、それを今回ご協力いただきながら進められたというところが本当にありがたかったです。このような手厚いサポートを受け、社内では「スリーシェイクさんを選んで正解だった」という声が上がるほど、高く評価しています。

私がQ&Aフェーズの中で難しいと感じたのは、実際にエンドユーザー様の環境で発生した問題に対応することですね。契約上、実際のエンドユーザー様の環境に直接アクセスして、ログなどの一次情報を確認することはできないので、今何が発生しているのかは宮脇さんにヒアリングを重ねながら、いただいた情報の中で推測して組み上げていく必要がありました。緊急で問題が起こっているので、限られた時間の中でなるべく正確に回答しながら問題解決をサポートする必要があるのですが、一次情報にアクセスできないという点はこのプロジェクト特有の難しさだと痛感しました。

いただいた情報だけですぐに勝手な憶測をせず、まずは必要に応じてしっかりヒアリングをして追加情報をいただくようにしました。例えば、クラスタにデプロイされているコンポーネントのバージョン、アプリケーションのいくつかあるAPIの性質、障害の発生タイミングや頻度といった、対象の環境や状況に関して情報収集・整理をして、理解を深めるように心がけました。

ＤＴＳ様には質問を結構多く投げかけてしまったりもしたのですが、嫌な顔一つせずに迅速に情報を提供してくださったので、素早い質問回答や問題解決に繋がったと思っています。

金融系の特性から、当初は正直すごくピリッとした雰囲気のプロジェクトなのかなと先入観を持って参画したのですが、宮脇さんをはじめ皆様が非常に話しやすく、ヒアリングへの回答も迅速にいただけて、気軽に質問することができたというところがすごく良かったです。

また、こちらの調査した内容の説明に対しても、宮脇さんをはじめ皆様が真摯に耳を傾けてくださって、不明点はその都度ちゃんと反応して質問をくださり、理解に努めようという姿勢だったため、非常に仕事自体が進めやすかったです。

定例会等では、メンバーの方同士で「ここはこうじゃないか」といった議論をされているところを見ていたのですが、すごくフラットに意見交換をされている様子が特に印象的で、風通しのいい組織なのだろうなと感じました。

こちらが考えてなかった視点で質問いただいたりすることもあって、技術支援している立場ではあるのですが、こちらも非常に色々学ばせていただいたと思っています。

今回は「SRE」の文脈で支援をいただいている中、我々からの質問がクラウドに関するものや、Keycloakの認証周り等、元々支援を依頼していた範囲から少しずれた部分の質問を色々させていただいたりしていたのですが、そういった部分に関しても調査してご報告いただいて、スコープを気にせず、サポートしていただいたことがとても助かりました。

「こんな質問も可能ですか」と尋ねたところ、営業の大澤氏が「もちろんです」と快諾してくれたため、我々もスコープを気にせず、幅広い技術課題を相談させていただきました。

今回の対応によって、コンテナ対応していることを強くアピールできるようになりました。提案先はビジネスユーザーよりも、IT部門の方が多いため、提案の場面では技術面の話も上がってきます。その時に、コンテナに関する話題、例えばEKSもECSもどちらでも対応可能といったところは非常に受けが良く、定量的な成果で言うと、具体的に2案件を受注できたのはスリーシェイクさんのおかげだとも思っています。

我々としても、コンテナ使っていますということを自信を持って言えるようになったことが、一番大きいかなと思っています。

これまでの金融機関のお客様との議論の中では、技術面、基盤面の話に及ぶケースも多々あるのですが、これを我々だけでやろうとしていたらおそらく立ち行かなかっただろうと思っています。プロジェクトを進めていく中でも新しい技術的なキーワードが出てきても、すぐスリーシェイクさんに相談できたという部分で、非常に安心感があり、本当にすごく助かりました。

今は案件から離れてしまっていますが、こういったお話を伺えて嬉しかったです。。

2案件受注できたというお話を聞いて、スリーシェイクが強みとしているコンテナ領域のスキルが、目に見える形でお役に立っていることがとても嬉しいですね。また、先ほど宮脇さんが支援内容に満足していただいているとおっしゃったことに、とても嬉しく思うと同時に、身が引き締まる思いというか、今後もその期待を裏切らないように、期待を超えられるような働きができたらいいなと思いました。

私も同じく、より丁寧に調査してちゃんと説明していこうと、これからも頑張っていきたいと思いました。

システム的な話から申し上げると、今は旧来のIaaSのベースをそのままコンテナに持ってきましたというところまでしか辿り着けていないので、せっかくコンテナに乗せられるようになったこともあり、マイクロサービス化を進めていきたいですね。それと、冒頭に申し上げた可用性の部分をもっと強化していきたいなというところが、今後力を入れていきたいところです。

今、AML業務は人手の作業が多いこともあり、できるだけAI化を進めていこうという流れがあります。AWSサービスと連携してAI活用の選択肢を広げ、AMLionのパッケージとAIのソリューションを合体させるようなことも今後やっていきたいと思っています。そこに対するご協力やご支援をいただけると、今までの関係性を生かしながらプラスアルファの取り組みができるのではと、個人的に思っています。

すごいですね。AIにも力を入れているのですね。

弊社もAI関連は力を入れているので、ぜひそこも一緒にやらせていただければと思います。

宮脇さんをはじめ、皆様が私たちの説明や回答に対して耳を傾けてくださって、わからない部分はその場で質問をしてくださいます。その分我々もちゃんとその場で回答できるようにしっかりと事前調査をする必要があります。

鋭い質問が来たりするので、少し大変な部分ではありましたが、宮脇さんが我々の準備した内容にいつも反応してくださるので、調査中も非常にやりがいを感じていました。

Kubernetesがメインの案件ではあるものの、それに限らずJava、PostgreSQL、Datadogなど色々な知識が求められたので、まさに技術の総合格闘技をしているような状態でした。そこに難しさを感じるとともにやりがいを感じて取り組んでいましたね。

これまでのご支援では、増山さんが整備したサービスメッシュやCI/CDに関する技術サポートが中心でした。今後は少し領域を広げ、可用性なども考慮に入れながら、お客様のサービスに対してより広範囲での貢献ができたらなと考えています。

SREの強みを活かし、CI/CD以外の部分についても、こちらから状況をヒアリングして改善策などを提案できるような活動もしていきたいと思っています。

ＤＴＳ様のパッケージは、先ほどお話に出た2案件に関わらず、今後も様々な金融機関様に導入されていくと思います。その点を見据えて、現在構築した環境をベースに、他の金融機関でも応用できるような仕組みを模索・提案していきたいなと思っています。