MetLife社のDocker MTA導入事例(前編)

こんにちは、クリエーションライン株式会社の鈴木いっぺいです。
普段はロスアンゼレスに在住し、米国各地のオープンソース系のITベンダーとの付き合いを通して、日本とのパイプ作りに専念する毎日です。

今回のブログは、Docker MTA導入事例の第3弾をご紹介したいと思います。DockerCon 2017やその後に数々のイベント通して、VISA International、MetLife、Northern Trustが同社でのDocker MTAの導入事例を発表しています。いずれも金融系の企業であることが特徴的ですが、一見ITに関しては手堅い印象の強い業界でなぜDockerの導入にそんなに積極的なのかを見ていきたいと思っています。

今回は、Dockerのユーザーとして多くのイベントに登壇している、MetLife社の導入事例について解説します。

DockerCon US 2017

まず初めに、4月17~20日、テキサス州、Austin市で開催された、DockerCon 2017における、MetLife社のプレゼン内容を紹介します。こちらの講演では、まだDockerの導入は実験的で、Dockerをベースとしてコンテナ技術の導入に取り組んだチームの組織化とその苦労した点を説明している内容が中心です。

MetLife, Inc.のTim Tyler氏によるプレゼンテーション

Tim Tyler氏がエンジニアとしてMetLife社に参加したのは最近ですが、入社早々、同社のDocker導入の任務を受け、新規チームの元、創業150周年を迎える企業のITインフラをコンテナ化させるためのプロジェクトに取り組む、という非常にチャレンジングなタスクを負っています。

この方は、2016年6月まではQualcomm社のエンジニアをされていて、その過去の経歴を見る分には金融／保険業界とは、ほとんど縁が無い方のようです。
それだけ、MetLifeという会社は、新しいITソリューションを導入する際、社内ではなく、社外からノウハウを持っている人を採用する戦略を取る必要性を感じている、ということが想像できます。

Docker導入のプロジェクトも、MetLifeが従来から支えていたIT文化から大きく異なるもの、という意識を持ちつつ、どれだけ早く新しい技術をモノにできるのか、そういった会社の新しい体質を作る、ということも一つの目標として立てられていたように感じます。

このスライドで書かれているように、たった5ヶ月である程度Dockerの導入実績を作った、という成果を主張しています。
恐らく、Dockerを導入したということだけではなく、一般的にレガシー資産の非常が高いFortune 40企業の中で、MetLifeは他と大きく違って、新しい技術に対する意識が高いこと、いざ動こうと決めたら早く動くことができる、という企業体質を持っていることを観客に伝えたかったように感じます。

まさに、全世界の企業がソフトウエア企業にならなければならない、という意識を具体的に行動で示す、一つのモデルのように思えます。

レガシーの代表者でもあるMetLife社は、来年には創業150年を迎える、ガチガチの保険会社です。
同社の販売している製品は「約束」。

この約束というものは、目に見えるようなものではなく、非常に "デジタル" なものであると述べています。（要は複雑な数字の計算に基づいて価値が決まるもの）
また、もう一つの特徴は、この「約束」は、非常に長い期間をかけてお客様に届けるものとのこと。（保険ゆえ、製品は一生かけてお客様に届ける場合もある）

このような特殊な環境における業種では、20年以上前から開発されて運用され続けているアプリも多く、今日のIT環境は非常に古いメインフレーム系のCOBOLアプリから、AWSで運用されているアプリまで混在している状況である、とのこと。

MetLife社は、資産価値が 57B＄を超えているだけではなく、50カ国以上にオフィスを持つグローバル企業でもあり、金融業であるがゆえに、それぞれの国での厳しいプライバシー規制、コンプライアンス要件やデータ保護の法律に縛られています。

そのような環境におけるITの開発はどうしても国ごとのITサイロで分割される傾向も高く、長いIT導入の歴史の中で、未だに運用されるメインフレームインフラ、UNIX、Windowクライアントサーバー、Linux環境、パブリッククラウド等インフラレベルから異なるアプリケーションの混在環境が築かれてきている。これらの分散／分割された従来の環境は、開発のスピード、すなわち企業のIT戦略は維持こそすれ、イノベーションを妨げる要因になってきました。

特に、世界的にもモバイルへのアプリの移行はニーズが急増しており、その開発スピードへの要求は深刻な状態です。
アプリを起案して、開発し、デリバーした頃にはランドスケープが変わってしまう、という繰り返しが続いていました。

Dockerの導入だけがこのレガシー企業のIT戦略のモダナイズに寄与したわけではなく、Dockerを軸とした、CI/CDコンセプトに基づいた、Plan/Build/Operate、という一貫したソフトウエアサプライチェーンの仕組みを作り上げることができたことが直接の成果です。

このモデルは、Dockerに代表されるコンテナ技術でないとできない訳ではありませんが、Dockerの技術を採用することによって、何も無い世界から、たった5ヶ月で、図に示される様なシステムを作り上げることができた、というのは顕著であると言えます。

Dockerを導入するプロジェクトは、まさにゼロからの出発だった、と説明しています。
経営側からは、かなり漠然とした要求で、かかるモバイルを軸とした戦略を支えることができるITインフラ環境を作れ、というもの。

そこで、現状の把握と、その中でどの部分を改善すべきか、DevOpsの観点から分析を行いました。

• まずは、Dockerを使用したサーバーのクラスタを構築し、アプリの開発／テスト／リリース／運用環境を作ることを目標とする
• MetLife内の従来型ウォータフォール型開発の状況把握

◦ 起案から開発計画策定、要求仕様の明確化、開発フェーズの定義など、のプロセスの理解
◦ 申請など、フォーム提出のプロセスの把握
◦ 作業依頼等のプロセスを起こすためのチケット登録方式の把握

これらのプロセスや仕組みを分析し、従来のウォータフォール型開発をほぼ全面的に廃止する必要性に至っています。
並行して、それに置き換わる、マイクロサービス型の開発方式、そこに組み込まれるコンテナ技術の方法論を具体化する作業に取りかかりました。

このプロジェクトを進める上で、専任の組織として、ModSquadというチームを作りました。（MetLife On Dockerの意味らしい）
チーム構成はいろんな人の集まりで、金融業界では珍しい、次のような特徴がありました。

• 半導体業界から来たばっかりの、金融業界をあまり知らない人間
• MetLifeに20年以上働いていた人もチームメンバー
• 大学卒業ばっかりの若い世代
• 男女半々の構成

また、既成のルールを捨てることを大きなテーマとしてあげることとして、次のキーワードに着目しました。

• Gene Kim氏の推奨するPhoenixプロジェクトと近い考え方を採用：Move fast and Fail fast
• Daily standup meetingを開催：毎日成果を報告する習慣をつける：ミーティングは短い
• Scrum手法を採用
• Kaban Boardも採用
• PostItも多用
• Disruptive Technologyを積極的に採用：とにかくスピードを実現する技術にフォーカス

Disruptive Technologyとして採用した技術は様々ですが、結果的に全てオープンソースを導入するに至りました。
現在、Docker Datacenterを利用していて（2017年4月時点）、今後、Docker 17.06 の導入を予定しています。
これらのツールでゴールの達成に大きく寄与したのは、Infrastructure as Code を導入するのに役立ったツール類です。様々なプロセスの自動化、パターン化、等が実現され、従来のウォータフォール型方式では人間がマニュアルで行なっていた（特に繰り返し）作業をコード化し、全て自動化することにより、スピードアップに加え、人間によるミスを防止し品質の向上にも大きく寄与しています。

一方では、技術サポート面での心配がありました。
何せ、新しい技術を導入する上で今までに無い課題が多く登場したためです。

• 技術サポートは誰に頼むのか？（OSSを開発しているのは大抵ガレージでたった一人でやっているんじゃ無いか、という先入観）
• オープンソースに対するガバナンスモデルが必要なのでは無いか？
• MetLifeの企業文化に本当に馴染むのか、という不安

企業の中にはオープンソースに対するネガティブな先入観が強い人も多いことがわかり、それを取り除くことが重要でした。オープンソースは規模の大きいソフトウエア企業と違って、コミュ二ティに支えられています。

Dockerの運用に関するポリシーや手続きなどを規定する必要がありました。

• DockerファイルやComposeファイルをどの様な規定に基づいて管理するのか
• アクセス権の管理をどうすべきか
• Docker Hubの管理責任者とその権限の範囲はどうすべきか

等、ガバナンスモデルを作り上げる必要性を感じていて、未だに完成しているとは言えないが、割と時間のかかるプロセスなのでできるだけ早めに着手することを進めたいとのことです。

Dockerを採用して最初に運用面で大変だったのは、開発したアプリがマイクロサービスアーキテクチャになったため、大量のサービスコンポーネントが生成されてしまったことです。これを管理するために、それぞれのクラスタエンジンやノードに詳細なラベルをつけ、そのラベルのルールを明確にし、管理することに務めました。

ラベルの種類として次のようなものがあります。

• 位置関係：ノード所在地、通信相手の所在地、管理者所在地、等
• ステータス：テストスクリプト、プロダクションシステム、多重化度合い、等
• 監視系：アラートの数、増減度合い、期待値、トラフィック量、等のチャージバック
• 成熟度：ノードの年齢、等
• 管理系：ノードの管理者／チーム名

これだけでも非常に大量のデータを多数のサービスから常に収集し続けないといけないため、タグ付けとラベリングに関してはかなり重要な要件として取り組みました。
全てラベル情報は、 com.company.docker.something.helpfull というルールで、統一的に規定されています。

Dockerの導入に伴って、もう一つ重要視したのは、Test Drivers Engineeringという文化を作ることでした。
広範囲なテストモデルを作ることによって、開発／リリースの品質、スピードの向上を実現する最短の方法だと気づきました。
多数のオープンソースコンポーネントを採用しているため、それぞれのコンポーネントの単位でのユニットテストや機能テストを作成し、それをBash方式で高速に、そして大量に行いました。

こればっかりは、自動化せずに、昔ながらの手作業で進めることが最も学習できる方法である、と判断し、QAチームのみならず、エンジニア、営業、マーケティングも巻き込んで、Excelスプレッドシートを共有しながらテスト環境を作りながら進めました。むしろ自動化しないことが、チームを育てるのに大きく寄与した例です。

テスト手法として一つ例をあげたいと思います。

War Gameの採用

• 開発チームと運用チームに分かれる
• 開発チームが任意の方法でシステムに障害を起こす。その方法は運用チームに教えない
• 運用チームがこの障害に対して、原因究明、切り分け、対策を行う
• 1週間かけて、この様なプロセスを繰り返す
• 全て工程はドキュメント化する
• 運用チームは、障害時のアラートやメッセージなどに対する改善を提案する

今後は次第にこのノウハウを自動化する方向に持って行く方針です。
その一環として、今週になって、BATS（バッチベースの自動化ツール）を採用することにしました。
上記のノウハウを自動化するために大きく役立っていて、今後Swarm Modeの本格導入で新規テストも増えていて、これらに活用する予定です。

常に完璧なデモを上層部に見せることができることにも心がけました。
これは最近気づいて導入したものですが、Graphanaを使って魅力的な可視化する方法を採用しました。

具体的には、デモを通して、一つのノードに意識的に障害を起こし、システム全体にその障害が広がる前に自動的に障害を検知し、その回復を行うまでのプロセスを、Graphanaで画面表示しながら見せる方法をとりました。もちろん、その間は、アプリ自体はレスポンスタイムに全く影響を受けずに正常動作を続ける、ということも並行して見せることができました。

このグラフィックなデモが、今回採用したDocker主体のマイクロサービス開発モデルへの理解と大きな評価につながった、と言えます。特に、MetLifeの海外拠点のCIOにこのデモを見せた時は非常にインパクトが大きく、DockerをMetLifeの海外拠点に展開する上で大きく役立ちました。

他にもトレーニングに関する経験談など、運用チームにDockerを紹介し、展開するまでの苦労話が多く登場しましたが、最終的にマイクロサービスがMetLifeにIT開発／運用に役立つことが認知されたことが本プロジェクトの更なる成長につながった、と言えます。

後編では、DockerCon Europe 2017でのMetLife社の講演をご紹介します。

関連リンク

DockerCon 2017のキーポイント
DockerCon 2017で発表された、Northern Trust社のDocker MTA 導入事例
VISA International社が見出した、Dockerのオーバーレイネットワークの価値
MetLife社のDocker MTA導入事例(後編)
Dockerの製品ページ