欧州最大の銀行であるSociete Generaleは、デジタルソリューションを活用してビジネスのあらゆる側面を再構築し近代化を図っています。
Dockerコンテナのような新しいテクノロジーを活用することで、Societe Generaleは顧客の新たな挑戦に合わせた付加価値の高いサービスを迅速に開発しています。
近代的なクラウドアーキテクチャへの道のりは、一朝一夕に実現するものではありませんでした。
段階的なアプローチにより、Societe Generaleは、セキュリティと信頼性を維持しながら、新しいインフラストラクチャに適応することができました。
本資料はSociete General DockerCon 2017プレゼンテーションからの転載です。
Societe Generaleは、総資産でフランス第3位、欧州では第6位の規模を誇る銀行です。
パリに本社を置く多国籍金融サービス企業であるSociete Generaleは、グローバル トランザクション バンキング、国際リテール バンキング、コーポレート＆インベストメント バンキング、プライベート バンキング、資産運用、証券サービスをサポートする部門を有しています。
Societe Generaleは、デジタル戦略を駆使して、個人、機関投資家、大企業、プライベートバンキングのお客様を問わず、お客様と銀行との関係を変革しています。消費者のデジタル利用の変化に対応するため、Societe Generaleは、ウェブおよびモバイルサービスの革新性を高め、お客様がより高い自律性、シンプルさ、安全性を享受できるようにしています。
誰もがDockerを使いたいと思っています
と、DockerCon 2017の聴衆に向けた話の中でSociete Generaleのミドルウェアスペシャリスト、Thomas Boussardon氏は語りました。
そこに到達するために、Boussardon氏とDevOpsアーキテクトのStéphan Dechoux氏を含むチームは、金融サービス企業でコンテナの採用とコンテナ・アズ・ア・サービス（CaaS）とプラットフォーム・アズ・ア・サービス（PaaS）のデリバリーのための計画を立てました。
プロジェクト開始から2年で、彼らはプラットフォームの構築に成功し、その上に20のアプリケーションを乗せ、コンテナ化のパイプライン上には50以上のアプリケーションが含まれています。
多数のアプリケーションを持っていることを認識する必要があります
とBoussardon氏は述べています。
これには、レガシーアプリケーション、サービス指向アーキテクチャ（SOA）、REST API、モノリシックアプリケーション、分散型アプリケーションが含まれます。
当行では、1500近くのアプリケーションがあります。私たちは、それらを同じインフラで正確に動作するようにしたいと考えています。
Societe Generaleのコンテナプロジェクトでは、セキュリティ、安定性、パフォーマンスを確保しつつアプリケーションをロールアウトしたいのです。 そのためにアジリティ、スケーラビリティ、自動化を新たなレベルに到達させることを目標に、我社のインフラストラクチャを変革し、統一化することを目指しています。
ユーザーエクスペリエンスを向上させ、アプリを簡単に展開し、簡単にアップグレードし、市場投入までの時間を短縮したいと考えています
とBoussardon氏は説明します。
ユースケースは変化しています。我々は今、インターネット上でAPIを公開できるようにしたいと思っています。すべてを安全に公開して、オープンバンキングを可能にし、数ヶ月後にはブロックチェーンを実現しなければなりません。チームは、Dockerの採用は一夜にして実現するものではないことを知っていました。成功を確実にするために、次のような4つの段階的な計画を立てました。
第一段階は、すでに導入されているものを評価することでした。
理想的には、既に投資しているソフトウェアとハードウェアのソリューションを統合し、新しいプラットフォームで利用できるようにしたかったのです。
現在存在するSociete GeneralのIT機器の規模を説明するために、Dechoux氏はセッションの聴衆に次のような質問を投げかけました。
もしデータセンターの機器をすべて積み上げた場合、そのタワーの高さはどれくらいになるでしょうか？
答えはエッフェル塔の8倍以上の高さです！
200年分以上のHDビデオを保存でき、グローバルファイバーネットワークはツール・ド・フランスのコースをカバーし、グリッドコンピュータの演算能力はメテオ・フランス（フランスの国家気象サービス）よりも速く天気予報を行うことができます。
私たちはすべてを再構築して作り直すことを望んでいませんでした。私たちにはアプリケーションやシステムがあり、それらを使う人がいます。私たちがやりたいのは、アプリケーションをホストできるだけでなく、すでに持っているものを利用できるプラットフォームを構築することです
とBoussardon氏は説明します。
Societe Generalが新しいコンテナ環境に移行したいと考えている既存のサービスには、CI/CD用のJenkins、ソース管理用のGitHub、アーティファクトリポジトリ用のNexus、永続的ストレージ用のNetApp、データレイク用のHortonworks、シークレット管理用のHashicorp Vault、サービスレジストリ用のConsulが含まれています。
また、開発スタックに使用されているツールも可能な限り維持したいと考えていました。
Javaアプリケーションでは、Netflixオープンソースソフトウェア、Spring Cloud、RabbitMQ、Zipkinが含まれ、.NETアプリケーションでは、.NET core、ASP.net、Open Web Interface for .NET（OWIN）が含まれています。
Societe Generalの次のフェーズは、コンテナを実行するためのDocker Engine、オーケストレーションのためのDocker SwarmによるDocker Universal Control Plane (UCP)、ストレージイメージへのDocker Trusted Registry (DTR)を特徴とするDocker Enterprise Edition (EE)の導入でした。
また、チームは継続的インテグレーションと継続的デリバリー（CI/CD）パイプラインの実践を進化させ、Dockerとコンテナのライフサイクルをテストと開発から本番まで適用しました。
このステップは、プロジェクトの最初の6ヶ月間で実施され完了しました。
Dockerを採用する前は、アプリケーションをホストするために仮想マシン（VM）とベアメタルサーバーを利用していました。
コンテナへの移行に伴い、チームは新しいプラットフォームでのビルドとデプロイのプロセスがどのように機能するかを定義することを課題としました。
Societe Generale は、開発者の混乱を減らすために、可能な限り既存の技術を活用した新しいワークフローを求めていました。
ビルドプロセスでは、JenkinsのマスターとJenkinのスレーブをDockerコンテナで実行し始めました。
今では、我社でアプリケーションを作るときには、GitHubやNexusからプルしたDockerイメージを使っています。
アプリケーションがテストされると、イメージはDocker Trusted Registry (DTR)にプッシュされ、アプリケーションを使用する権利を持つ誰もが容易に利用できるようになります。 Societe Generaleのデプロイプロセスも同様のワークフローに沿っており、デプロイをスケジュールしたり、変更が行われた後や新しいイメージが利用可能になったら自動でデプロイを開始したり、チームがアプリケーションの再デプロイを決定した場合には手動でデプロイを行ったりと、柔軟に対応しています。 本番のロールアウトでは、Societe GeneraleはDocker UCPを利用してDockerワーカーにコンテナをデプロイするための命令を送信しています。
次のフェーズでは、プロジェクト開始から10ヶ月が経過した時点で、Societe Generaleはアプリケーションの本番運用への導入を開始しました。
この期間中に、本番環境での運用を確実に成功させ、より幅広いアプリケーションをサポートできるようにするために、プラットフォームの機能を成熟させるために何が必要かを定義しました。
ここで、3つの重要事柄が特定されました。
第一に、アプリケーションによって作成された重要なデータを確実に保持するために、ステートフルコンテナをサポートする必要があること。
第二に、コンテナ化されたインフラストラクチャとアプリケーションの可視性を提供するために特別に設計されたモニタリングソリューションの要件も定義すること。
第三に、モニタリングソリューションと連携して環境のロギングを実行する方法をアップグレードすること。
Societe Generaleでは、コンテナ環境で既存のインフラストラクチャを再利用するという目標を満たすために、NetAppストレージを活用してDockerでステートフルなアプリケーションのデータを安全に保持できるようにしました。
環境内では2つのDocker Volumeプラグインが利用されており、1つはNetAppのNFS用、もう1つはNetshareのCIFS用です。
この機能が整ったことで、当行ではステートフルなアプリケーションを実行できるようになりました。
これらのステートフルサービスの例としては、Jenkins Master、ElasticSearchを搭載した同社のELKスタック、バッチジョブによって生成されたデータなどがあります。
情報を失うことなく再起動できる必要があります
とBoussardon氏は強調します。
これらの対応により、Societe Generaleはステートフルアプリケーションを導入し、そのコンテナがクラッシュしても情報を失うことなく再起動できるようになりました。
コンテナ監視のためにSysdigを選択する。
コンテナの監視は、サーバー、IP、ポートを知っている、これまでのアプリケーションの監視とは異なります。 コンテナでは、同じようにはいきません。
とBoussardon氏は説明します。
コンテナでは、すべてが毎回変わります。 アプリケーションは、同じノードで実行されることはなく、同じIPで実行されることもなく、同じポートで実行されることもありません。 私たちはこれを監視するソリューションを見つけなければなりませんでした。 それがSysdigを使うことにした理由です。 Sysdigは、コンテナで何が起こっているのか、内深く調査する方法を提供してくれます。 ダッシュボードを提供してくれるだけでなく、メトリクスとすべてのログをデータレイクに送信してくれます。
Sysdig Monitorにより、チームは物理環境内だけでなく、コンテナ内で何が起こっているかを確認することができます。
開発チームと運用チームは、コンテナ化されたインフラストラクチャのすべてのレイヤーでリソースの使用状況を監視し、アラートを出し、トラブルシューティングができるようになりました。
これらの洞察を得て、Societe Generale は以下のような問題を特定し、対処することができるようになりました。
ContainerVisionを搭載したSysdig Monitorにより、Societe Generaleは以下のことが可能になりました。
導入の初期展開では、Sysdig Monitorソリューションをオンプレミスに導入し、PaaS内の内部インフラのメトリクスを収集できるようにしました。
この対応により、Societe Generaleは既存の設備投資を活用し、セキュリティとコンプライアンスの要件を確実に満たすことができました。
Societe Generaleはプロジェクトの次の段階に入ると、プラットフォームは、モダンなアプリと従来のレガシーアプリの両方を含む多くのアプリケーションを積極的にサポートしていきました。
プロジェクトが開始されてから15ヶ月後のこの段階で、同社はマイクロサービスとしてのアプリケーションの導入を開始しました。
彼らはアプリケーションの並列実行を可能にするアプローチを使うことで、本番環境でコンテナ以外のインフラストラクチャ上のアプリケーションを継続実行しながら、同じアプリケーションをコンテナ上で同時に実行するというものでした。
Dechoux氏は次のように説明します。
当行にはすでにVMやベアメタル上で動作するマイクロサービスがありますが、Dockerに移行できるようにしたいと考えていました。 カナリアリリースやブルーグリーンデプロイの方式で、同じサービスをコンテナでも並列実行したいのです。
このようなクロスプラットフォームのサービス構成でアプリケーションを実行するため、Societe Generale はコンテナの外側でサービスを管理することにしました。このアプローチを取ることで、チームはコンテナの原則である、コンテナイメージの不変性を維持しながら、アプリケーションに必要な設定、シークレット（例：APIキー、パスワード）、証明書を実行時に注入することができます。
私たちは開発中に一度だけイメージを構築し、同じイメージがすべての環境（UITインテグレーション、プリプロダクション、プロダクションなど）に適用されるようにしたいと考えていました。
とDechoux氏は説明します。
このフェーズでは、Societe GeneraleはConsulで管理しているマイクロサービス環境のトラフィックを制御するため、"L7-as-aService"を提供するコンテナ型ダイナミックL7ロードバランサーのFabioも導入しました。
FabioはConsulのサービスレジストリをチェックし、検出した状態変化に対応します。
Societe Generaleはコンテナ化されたアプリケーションごとに専用のFabioコンテナを実行します。
Societe Generaleのコンテナプロジェクトのこのフェーズの最後の焦点は、セキュリティの向上でした。
堅牢で堅固でなければなりません
とDechoux氏は説明します。
このプロセスの重要なポイントは、イメージの脆弱性をスキャンするDocker EEの組み込み機能であるDocker security scanning (DSS)を利用することでした。
チームはまた、すべてがベストプラクティスに従っているか確認することを目的として開発された社内のリンターツールを使用して、Dockerfileをスキャンし、ファイルを作成します。
将来を見据えて、Societe Generaleは、次の1年で達成したい目標を明確に設定しています。
その中には、パブリッククラウドの導入、より多くのクロスプラットフォームアプリケーションの展開、パフォーマンスとセキュリティの継続的な改善が含まれています。
夢は、Amazure - AmazonとAzure - と自分たちのサイトの間に、ある種のクロスクラスターのような、とても巨大なクラスタのようなものを持つことです
とDechoux氏は言います。
Boussardon氏は次のように付け加えます。
我々は独自のプライベートクラウドを持っていますが、オーバーフロー対策のためにデータセンターをまたいで、AmazonやAzureのようなパブリッククラウドへ移動できるようにしたいのです。そのために他のデータセンターや他の環境にもイミュータブルにアプリケーションを展開したいと考えています。
この目標を達成するために、同社は "Software-Defined Everything "(ソフトウェア定義をすべてのものに)のビジョンを示しています。
これには、VM、ベアメタルサーバ、コンテナなど、あらゆるものの間のネットワークを標準化するためのsoftware-defined networkingへの移行も含まれます。
また、software-defined storageは、ストレージの提供方法を改善できる技術であると考えており、ゴールド、シルバー、ブロンズなどの異なるクラスのサービスを顧客に提供し、多様なアプリケーションの要件を満たすためのパフォーマンスと永続性に関する機能を選択できるようにしています。
Societe Generaleは、その事業の性質上、各段階でセキュリティの強化にも熱心に取り組んでいます。
LEVEL 4のフェイズでは、セキュリティポリシーの実施に焦点を当てています。
当社は銀行ですから、至るところでセキュアであることを要求されます。
とDechoux 氏は言います。
例えば、rootとして何かを実行することはできない、コンテナにホストボリュームをマウントすることはできない、ある種のコマンドを実行することはできない、binディレクトリを変更することはできない等々のルールを作成できるようにしたいと考えています。 セキュリティを確保するために、すべてのコンテナに動的に適用できるポリシーを設定したいと考えています。 特にDMZで公開したい場合は。
Societe Generaleは、プラットフォームを強化し、顧客に付加価値の高いサービスを提供するために、何ができるかを考え続けています。
その一つの可能性として、コンテナオーケストレーションを実現するKubernetesの使用が挙げられます。
それは議論になるでしょう。 開発者はデプロイ用のkube fileを用意したいのか、それともDockerツールを好むのか。 我々はそれを確かめることになると思います
とDechoux氏は言います。
DockerConのプレゼンテーションの最後に、Dechoux氏はまた、彼らの銀行が興味を持つ以下の4つの技術分野について説明しました。
Societegeneraleにとって、コンテナへの移行は 新しい熱意を生み出しました
以前は1年かかっていたことが、今では3ヶ月で達成できるようになりました。
我々の銀行では現在、フォロー・ザ・サンモデル（時差のある地域に拠点を分散することで24時間稼働を実現する方式）を採用し400人以上の開発者が1時間区切りの時差をおいて働いています。誰もが新しいプラットフォームに参加したいと思っています。 誰もが、プラットフォームの移行を支援したいと思っています。 UNIXチームも、ストレージチームも、開発者チームも、皆を助けたいと思っています。 誰もがDockerを利用したいと思っています。 社内のマインドセットの変化です。 誰もが１つのプロジェクトに携わっているのです。
とBoussardon氏は強調します。
すべてを同時に行うことはできません。
プラットフォームで活躍できない人を選出することは、フラストレーションを生み出すだけです。
ステートフルに出来ないのに、なぜステートフルでやりたい人を選ぶのですか？
いくつかの評価を行い、候補者を選びましょう。
あなたが持っている情報から、候補者の多くが使っている機能がみつかるはずです。
そこから始めましょう。
誰もがDevOpsの話をしますが、実際に思っていたものとは違うのではないでしょうか。
Devの側ではすべてが可能で、すべてが簡単です。
それがOpsの側ではすべてが不可能になります。
いい方法を見つけるには、インフラストラクチャにコアチームを据え2つの世界を渡り歩く必要があります。
