デルタ航空のビジネス変革 OpenShiftを使いながら安定性と持続性を両立させ、アジリティを向上した話

みなさんこんにちは、Red Hatでソリューションアーキテクトをしている金森です。

唐突ですが、なんとRed Hatと書く際にはRedとHatの間に[半角スペース]が入ることをご存知でしたか?

実はredhatでもRedhatでもなく、Red Hatが正しい会社名記述です。
今日はこれだけ覚えてもらえると本当に嬉しいです。

Red Hat社内の人間もついうっかり間違えて使ってたりするので、Red Hat半角スペース警察に取り締られたりします。

ぜひ、みなさんも身近な半角スペースなしRed Hatterを取り締まってみてくださいね!


さて、大事なことは伝え終わったのですが、10/16にOpenShift 4.2がリリースされました!

今回のリリースも様々な見所が数多くあるのですが、それはさておき

  • そもそもPaaSとかOpenShift(k8s,コンテナ)ってなんの旨味があるの?
  • どんな効果を出しているの?DXとどう関係あるの?
  • 既存システムのコンテナ化ってどう考えればいいの?
  • 新しい基盤だけ入れればいいの?

という素朴な疑問を持っている人もいると思います。

何かしらのヒントになればと思い、このポストでは残りの余白を使って今年5月のRed Hat Summitで発表されたユーザーの事例を紹介しようと思います。

前回はMicrosoftの17,000台のネットワークをAnsibleTowerで自動化した事例を紹介しましたが、
今回はRed Hat OpenShift Container Platformのヘビーユーザーで世界第2位のエアラインDelta航空の事例、
Driving agility in business transformation at Delta Airlines with stability and sustenance(意訳:ビジネスの変革を成し遂げるため、デルタ航空ではどのように安定性と継続性を両立させたままアジリティを向上させていったのか)をお届けします。

スピーカーであるデルタ航空のディレクター Doug Keskey氏がOpenShiftをどのように使い始めたのか?そのテクノロジーをどう最大限に活用しているのか?既存アプリケーションを何から移行させたのか?を解説します。

紹介するセッションのフルの資料やアブストはRed Hat Summit 2019のページから確認できます。

ではこのセクションより、セッション本編に入りたいと思います。


Driving agility in business transformation at Delta Airlines with stability and sustenance

f:id:canalroy:20191018143723p:plain
タイトル

デルタという会社とエアラインというビジネス

f:id:canalroy:20191018143935p:plain
デルタ航空 Doug Keskey氏

デルタ航空はアメリカにある世界で最も大きな航空会社のうちの一つです。300以上の国内線があり、国際線も数多く飛ばしています。
我々が人を雇う際の口説き文句でよく言うのですが、このエアラインで働くと言うことは単純なキャリアを積むと言うことではなく、あなたの生き方に繋がることになるだろうと言ったりもします。
Deltaにいる限り、世界があなたの挑戦する場で、そこがあなたの生きる場所なのだと。

航空会社と言う領域で働く上で、とても面白いメジャーな問題として、エアラインの運行は、それ自体が非常に複雑な物流の上に成り立っていると言うのがあります。
あなたが飛行機に乗るとき、まずゲートで登場手続きをしたのちに飛行機へ乗り込みますが、あなたや乗客、それと同じく動く預け荷物、その他の飛行機運行に必要なもの全ての可動部分を考えるなら、乗客、そこに必要な乗組員、飛行機の整備、運行、ケータリングなどなど、とても多くのロジスティックと最適化が必要になってきます。

それらの問題は516の主要な都市への直行、乗り継ぎを含めたフライトで、毎日5,000回程度発生しています。またそこには提携航空会社との連携も発生します。

デルタ航空は Fortune 500で最も尊敬すべき会社にも選出されたこともあり、お客様に選んでいただいていると言うことを自負もしています。実際、過去9年間トラベル・航空会社のカテゴリーで1番の評価をいただいています。

トップ企業であると言うことは、いつか追い抜かれるかもしれないと言う状態かもしれませんが、我々はそうならないよう毎日とても楽しく仕事をしています。

従業員の働く環境についても、透明性がとても高く軍隊のように非常に厳しい評価をすると評判の調査会社の調査結果においても、女性やマイノリティのメンバーにとっても素晴らしい場所であると言う評価を得ています。
そういったこともあって、非常に良い状態を保ててるのではないかと思っています。

一方で、ビジネス上の問題を解決するということについても、とても楽しい状態で進められています。
それもあって、デルタ航空というのは働くのにはとても良い場所と言えるでしょう。

創業90年の会社がビジネス変革のために実現するアプリケーション・モダナイゼーション

さて、ここからまず我々の全体的なアプリケーション・モダナイゼーションのイニシアチブについてお話しましょう。

f:id:canalroy:20191018144949p:plain
デルタの変革ジャーニーにおけるイニシアチブ

デルタは創業90年でメインフレームの時代からITを活用してきたため、社内には多岐にわたるアプリケーションが溢れていました。

90歳の会社を想像してみてください。

社内には90年代どころではなく、おそらく70年代ひょっとしたら60年代から動いている何かを簡単に見つけることができます。
デルタ航空のアプリケーションポートフォリオの大部分は、過去25年から30年に渡って開発されており、最近では腐ったシステムの上にさらに新しい機能を追加構築するような傾向がありました。

そのような状態に対して、我々はアプリケーションをより俊敏に移行できる方法を知ろうと試みました。
また多くの技術的な負債を引退させる方法を実現しようとしています。

所有しているアプリケーションの俊敏性を高め、技術的な負債(例えばスケールを簡単にできるようにしたいのに、旧式アーキテクチャに囲い込まれているためできないようなもの)を引退させるためアプリケーションの変革を決意しました。
これらの新しいテクノロジー領域、クラウドベースのテクノロジーを適用することができれば、動的なスケーリングができるなどができれば、アプリケーションのデプロイをもっとダイナミックにし、レバレッジを変えることができるのではないかというところがモチベーションです。

OpenShiftは我々にとってPaaSの機能を提供してくれたプラットフォームでもありますが、単純に基盤を作り直す・保有する、というリソースの観点だけではなく開発プロセスやそれに関わる様々なツールも刷新することが重要だと感じており、まさにそれらも提供してくれるものでした。

アプリケーションモダナイゼーションを行うプロセスにおいては、DevOpsの方法論で、PaaSをツールとして利用し、CI/CDタイプの開発プロセスを全てのアプリケーションへ採用・適用しました。

これらはモダナイゼーションという目的を達成するための手法として必要なことでしたし、これらを採用することで実際にモダナイゼーションが達成できていると考えています。

一つの大きなポイントとして、セキュリティの確保がありました。
Red Hat Summitの基調講演でも弊社のCIOがお話した通り、セキュリティの観点でも確実にかつ簡単に管理ができるものを利用する必要があります。
確実なセキュリティを確保する要素もCI/CDのプロセスへ組み込みました。

現在では、プラットフォーム自体のセキュリティを維持するだけでなく、プロダクト内でCodeとしてセキュリティを実装・維持できるようになったと考えています。
実際にCI/CDプロセスにおいて、自動的なスキャニングを実施しコード上でもセキュリティを維持できています。

Delta航空のビジネス変革 3つのプログラムイニシアチブ

f:id:canalroy:20191018145824p:plain
3つのイニシアチブ

少しお話をしたように、他のイニシアチブもあります。
スライドの一番右に書いてある技術的なアップグレードについてはここまでに少しお話しました。
また最新のプラットフォームでセキュアにたくさんのものを実行できて、さらに迅速になったということを簡単にお話したつもりです。

一番左(Dojo Program)について。
これが本当に困難でした。
ビジネスプロセスの革新について、開発チームと話をするのは本当に大変でした。
開発者、MBA、ビジネスパートナーなどを巻き込み、アジャイルタイプの開発手法論へとシフトさせたのです。
ここではこれらについて多くを言及しませんが、このDojoプログラムを無しには、全ての関係者の間にあった距離感をなくしワンチームとするのは本当に困難だったと思います。

3週間でアジャイルチームを立ち上げ、当たり前のようにPaaSやツールセットを使いこなし、DevOpsを実現する教育プログラム

f:id:canalroy:20191018145927p:plain
Dojoと名付けたアジャイルチーム育成プログラム

デルタでは、Dojoプログラムという名前で集中してPaaSを利用することについて学ばせることにしました。

具体的には、3週間でチームを立ち上げ、アジャイルに適用させます。 APIの使い方、DevOpsのやり方を学びます。
デザイン思考、アジャイル、クラウド技術など、プロセスに関わることなどです。

そのための、強力なツールのセット、それらをどう使って新しい開発を行うのか、ボトムアップで設計し、学ぶことで、テクノロジーを最大限に活用しアプリケーションを設計することができます。

このスライドに記述されているものは、実際に現在デルタで実行しているプログラムの一つです。
これらの手法はYoutubeでも公開しています

f:id:canalroy:20191018150234p:plain
PaaSの採用とテクノロジーの活用

現在、我々は明確にPaaSへ移行しようと考えており、戦略的にもOpenShift Platformを採用しています。

技術的な詳細は話しませんが、テクノロジーをいかに組織論やプロセスにつなげていくかについてをお話します。

繰り返しますが、我々は数百から数千の既存アプリケーションを抱えていました。

我々のプロジェクトは、2つのトラックからなってます。
インフラストラクチャのトラックでは、十分なコンフィグレーションセッティングやインストールなど、基本的にどうすればプラットフォームを利用できるのかを十分に知るための準備を実施します。

もう一つは開発コミュニティ向けトラックです。
企業向けのアプリケーション開発を志向しています。これらに開発ルールを適用し、アプリケーションを効率よくPaaSに取り込んでいく方法を見つけていきたいと考えています。

製品採用から既存アプリケーションのPaaS移行の道のり

f:id:canalroy:20191018150404p:plain
DeltaのPaaSジャーニー

PaaSへの移行対象は、全く新しいアプリケーションではありません。 既存のアプリケーションから選定しました。
また、我々は移行の中で既存アプリケーションを止めて、アプリケーション全てを書き直すようなつもりはありませんでした。
色々と考えた末、長年のパートナーシップにあったTCS(タタコンサルティングサービス)と協力しました。

PaaSへの移行において、複数あるアプリケーションのうちからどれを選ぶのか?しかも600~2000くらいあるアプリから。
その中に、非常に環境と密接に結びついているアプリケーションがありました。
つまり、モノリシックなアプリケーションをPaaSへコンテナ化して移行してみました。
大きなモノリシックアプリをコンテナ化したのです。
必ずしも、マイクロサービスやそれに類するものに分割するのではなく、アプリケーションを利用するために必要なOpenShiftへの移行作業だけを行いました。
それだけでも現状クラウド化した効果はでています。

本当はクラウドネイティブのような作りが望ましいのでしょうが、それらはもっとグリーンフィールドタイプの開発や、より初期の開発であったり、幾つかの理由で完全にリファクタリングするような場合にのみ実行することにしています。

このセッション内で話すのは、既存のアプリケーションをコンテナ化したという話です。

デルタは、様々な製品と検討・比較したのち、2017年にOpenShiftをデルタのPaaSに位置付けるという戦略的な決定をしました。

その後、2018年初頭に、パイロットアプリケーションを構築し、APIを実行したりしました。
それらのいくつかは今も本番環境で稼働していますし、その頃(2018年第一四半期)も相当に満足をしていました。

しかし、試みを加速させるためにはプラットフォームの能力を引き出す必要があります。
そこで、2018年の第二四半期では再度メソドロジーを理解するためのプロセスを実行しました。

簡単に聞こえるかもしれませんが、非常にハードで、経験豊富なチーム(TCS)と協力する必要がありました。

第三四半期に作業を開始し、おそらく40程度のアプリを並行してオンボーディングしました。
そして年末には実際に環境下へ新しいプロセスを通してアプリケーションのデプロイを行えるようになりました。

現在では、さらに多くのアプリケーションを追加できていますし、スケールアップしてきています。
実際に物理的な調達が間に合わず一時的なリソースでOpenShiftを稼働させ全てのアプリケーションを構築てもらったり稼働させたりもしました。
それらはテンポラリであり恒久的な環境ではなかったのですが、おそらく、私の見解ではユーザはそのような状況だったとは気が付いてもいないでしょう。
新しい環境にコンテナを移動させ、実行することは非常に簡単に実行できました。

そして2019年の第一四半期の終わりまでにプロダクション環境への移行は非常にうまくいきました。

その結果として、我々はさらに大胆になって行きました。

ミッションクリティカルなアプリも移行対象へ

移行対象にはミッションクリティカルなタイプのアプリケーションもありました。
35年以上航空会社で生き残りたいなら、クリティカルではないアプリケーションを移行対象として選ぶべきなのでしょうが、正直重要でないアプリケーションを移行したとしてもあまり意味も価値はありません。

結果的に57のアプリケーションを本番環境へ移行しました。

現在は、このインフラストラクチャを利用して俊敏性を高め、DevOpsを実現し、プラットフォームに依存しないアプリケーションを追加していけることを楽しみにしています。またこのテクノロジーを利用してさらにアジリティを高めていくことも計画しています。

我々の環境に合わせ、複数の物理的な場所にまたがり、アプリケーションを展開することも検討しています。
ですが今日はパブリッククラウドについては多く言及しません。

私たちが目的としていたことは、OpenShiftのPaaS環境を用いて、アジャイルとDevOpsをベースとした組織を作り上げ、アプリケーションのデリバリーを加速することでした。

そのためには、先ほども言いましたがDevOpsの手法なしでは絶対に成し遂げられません。

実際やってみると、アプリケーション自体の多くはわかりやすく、簡単な移行でした。
もちろん、少なからず影響はあり、そのためにいくつかのアプリケーションは更新したり、クラウドフレンドリーな形へ変更してあげる必要がありました。

それらの変更を実行するためにOpenShiftの環境があるので、大切な要素である、”12ファクター”を知っておく必要がありますし、基礎となるプラットフォームから様々な依存を分離させた形でアプリケーションを実行する形にすることが重要なカギになります。

こういった重要なポイントからも、我々はナレッジと専門知識を持ったチームを作りたいと考えるようになったのです。
重要なポイントを理解し、何かのアイディアが生まれたならば、それらをサポートするプロセスを確立する必要があると考えました。ビジネスを作り出すプロセスとして現行の開発手法の再構築を試みたのです。
そして、そのプロセスを通じて、チームをハンドルする必要があったのです。

我々はアプリケーションを開発する手法を変えました。

また、Day2オペレーションにおいては、先進的な開発リードをするチームが去ったとしてもアプリケーションをサポートができる状態が必要です。
そのような状態を作ることも目的でした。

Day2オペレーションにおいてビジネスを停滞させないために

f:id:canalroy:20191018152710p:plain
運用モデルについて

ではどうしたのか?

Operating Modelを確立しようと考えました。
中央集権的なチームを作りました。それらを中心とした、オペレーティングモデルです。

いかにPaaSを使いこなすか、移行、パフォーマンス監視や運用、Toolの使いかたまで含めたプロセスをこのチームが提供しています。

デルタのメンバーも、最初は自分たちのレガシーアプリケーションを単純にどう個別に運用するかを考えていましたが、だんだんとどうやって効率よく最新のDevOpsツールやOpenShiftを使いこなすか、移行するかを考えるようになり、彼らをPaaSのアクセラレーションチームがサポートしています。

またこのプログラムを通じることで、これまでどのように既存のアプリケーションをケアしてきたかもわかるようになってきます。
プラットフォームチームのメンバーも開発者とペアプログラミングを実施しています。
開発の仕方、アプリケーションの移行の仕方をツールもセットで学びます。
結果、アプリケーションをプロダクションへ移行する準備ができますし、サポートする準備もできるようになります。
彼らがこのプログラムから卒業する時には移行準備ができているということです。

そして次のような方法論も整備しました。

既存アプリケーションをPaaSへ移行するための方法論を確立

f:id:canalroy:20191018152952p:plain
既存アプリケーションのPaaSへ移行するまでの道のり

PaaSでアプリケーションイメージを実行するには、いくつかのコードをアップグレードする必要があったりします。
しかし、その他の要素で我々はCodeのUpgradeを行なっていました。

それは、開発チームが開発中に利用できるDevOpsツールを利用できるようにアプリケーションを移行することでした。
そしてこれらのツールは私がdojoプログラムの中で少し話したものでもあります。
これらの利用されているツールは、全てのチームが非常に愛用しているツールです。これらは私たちのPaaSを提供するという労力からは独立したものです。
それにもかかわらず、利用されているツールは私たちがPaaSで提供しているものと一致しています。

人とアプリケーションがDevOpsツールを利用できるようになったら、次にPaaSでサポートされているイメージを実行するため、アプリケーションを揉みほぐしていく必要があります。

PaaSを活用するため、 『12ファクター』に合わせていくのです。

ロギングとモニタリングを標準化したりもします。
デプロイメントも完全に自動化しました。
これによって、アプリケーションの開発チームがプラットフォームチームと会話をしつつ開発を行えるようになりました。昔から連携はしていましたが、今はよりスムーズになりました。

車輪の再発明を防ぎ、ビジネス変革へ開発チームをフォーカスさせる

f:id:canalroy:20191018153122p:plain
40以上の実装のパターン化

中央集権的なグループを作ることの先ほどとは異なった観点でのメリットは、様々な実装のパターン化ができるという事実に基づくでしょう。
実装における車輪の再発明を防ぐことができるのです。
我々は40ほどのパターンを確立してそれらを当てはめて行きました。
それらをお全てテンプレート化したのです。

プラットフォームチームとの協力の結果、このページに書いてあるようなとても素晴らしいインデックスを作ることができました。

f:id:canalroy:20191018153244p:plain
PaaSを使うことによるメリットとは

これは、私から見たプロセスなど含めて一般的な利益をまとめたようなスライドですが、私が認識した利点をあげます。

環境が一貫していること。
これは本当に素晴らしく、これまでのように存在していないものや不確実なものに対してテストを実行するようなことが一切なくなりました。

レジリエンス。
ブルーグリーンデプロイメント。
扱いやすく、ポータビリティがあることなど。

こういった利益を本番環境で確認し実感できたことが、本当に私自信を興奮させました。

f:id:canalroy:20191018153349p:plain
Deltaで使われている他のRed Hatプロダクトたち

他にも、Red Hatのプロダクトを利用しています。
ここでは使用しているいくつかを紹介します。

Ansibleは強力な自動化のツールで、PaaSを取り巻くNWやストレージ、PFの領域や運用の領域で使われており、AnsibleTowerによって様々な3rd Party製品やチームとの連携を可能にしています。リードタイム削減をしてアジリティを高めるために本当に良いツールです。

RHELもセキュリティ担保のための基本的なパーツですし、限定的なアクセスのみを許可している閉ざされたEnterpriseなNW環境で迅速な開発を行うにはSatelliteがなければメンバーは形だけの意味のないセキュリティのおままごとで無駄な時間や手間を生み出すことになるでしょう。
そういった塀だけを高くすることがエンタープライズのセキュリティであるという考え方に基づいたプラットフォームや運用は、やがて全てに悪影響を発生させ、限定的で意味のない開発プロセスを作りだしますし、塀の中の本質的なセキュリティ脆弱性はいつまでも埋めることはできないでしょう。

f:id:canalroy:20191018153445p:plain
PaaSへの道のりでの学びとは

ここではスライドの2番目のポイント(Enterprise application pre-assessment and repeatable pattern identification)について話しましょう。

確立した40のインテグレーションパターンについて述べました。
これをやがてはアプリケーションにも持ち込みたいと思っています。
アプリケーションではいくつか課題もあるかもしれません。しかし、今我々はそれらを環境に持ち込むために色々な厄介ごとを取り除く良い方法をすでに持っているのです。

プラットフォームチームと協力してすでにOpenShiftのマーケットプレースカタログにテンプレートの追加も実施できました。

共通言語を学び、組織を変革し、Fun journeyを続けるDelta

私たちが抱えていた最大の課題は、全員を集めて共通言語を学ぶことでした。
単純にいってしまうとツールとプロセス、設定方法を学ぶことです。
組織全体をまとめることで、共通のツールを学ぶ動機付けをし、この学ぶというプロセスの中でさらにたくさんのことを学びました。

トレーニングをする、というのも大事ですが、実務を目の前にした時にトレーニングで得た概念は消えてしまいます。
ホワイトボードの上で描かれることと、キーボードを用いて実行されることは単純に見えるけど同じにすることは本当に難しい。
結局、いつかは開発者の考えを変えなければならない。
これらの道のりは本当に大変だった。

でも、“It's been a fun journey”です。

以上で私の話を終わります。
ご静聴どうもありがとうございました。

f:id:canalroy:20191018153558p:plain


Delta航空のOpenShift導入事例、いかがでしたでしょうか?
皆さんのDXの参考になれば幸いです。

ではまたどこかでお会いしましょう!
Red Hat金森

今すぐ試したい人はこちらからどうぞ

OSSの最新事例やセミナー情報をGetしよう www.redhat.com

* 各記事は著者の見解によるものでありその所属組織を代表する公式なものではありません