OpenShift を活用してデリバリのリードタイムの短縮した事例
The fast-moving monolith: how we sped-up delivery from every three months, to every week – RHD Blog で紹介されている KeyBankでのリードタイム短縮のチャレンジを要約してみました。
リリースサイクルを3ヶ月から1週間へ
ここで紹介されているのは、KeyBankのリリースサイクルが四半期ごとから毎週になったという話です。
リリースサイクルを短縮するにあたっては、WebSphereからTomcatへの移行と、コンテナのランタイムとしてOpenShiftの採用
これらの変革を最重要プロジェクト(The digital channel modernization)の一環として実施
課題
- SLAを満たすようにメンテナンスするにはコストがかかる、典型的なモノリシックなアプリケーション
- 四半期リリースは、コストが高いしリスクも高く、週末の一大イベント (もちろん月曜日にはちゃんと使える状態になっていなくてはならなりません!!)
Motivation
担当者が色々と調べているときに、カンファレンスで Netflixのプレゼンを見て、自分たちよりも2-3倍の規模なのに、リリースに関わるメトリックは自分たちのそれをはるかに超えていることを知りました。 そして、銀行のDigital Channel にはウィークリのリリースは合理的であると考えました。
このプロジェクトでやったこと
- 古いアプリケーションをモダンなモバイルでも利用可能なウェブアプリケーションにすること
- プレゼンテーションレイヤとビジネスロジックレイヤを分離して、CI/CD が実現しやすいアーキテクチャにすること
- 自動化を推し進めてリードタイムを短縮すること
- 時間を浪費していた承認プロセスを削減すること
アプリケーションアーキテクチャ
対象のアプリケーション
かつて流行っていた構成でした。
新しいアーキテクチャ
- AngularJS と Ionic を採用
このプロジェクトを進めていく過程で直面した課題
Ops との戦い
アーキテクチャを変更しJAX-RS を使うためには、JDK1.7が必要でした。しかし、Ops チームはやりたがりません(寝た子は起こすななので)。しかし、 JDK1.6のサポートライフサイクルが半年で終わってしまうとサポートされた環境でシステムを運用したい Ops もやらざるを得なくなりました。
Dev vs Ops
Dev は正しい方法で自分たちのニーズを伝えられず、Opsはシステムがサービスを継続できる状態を保つことが気がかりで、新しいことにチャレンジしたがりません。 この板挟みでモデレートすることに苦労したようです。
必要なプラットフォーム
デリバリチームは、自分で必要なインフラはセルフサービスでプロビジョニングできるべきと悟り、それを実現するにはプライベートなクラウドインフラが必要という結論に達し、それには Kubernetes が最適となりました。
最適なプラットフォームはOpenShift
WebSphere で動いている古いMVCモデルのアプリケーションをモダンな技術に移行することは技術的には問題ありませんでした。しかし、以前として課題は、週次のリリースとインフラのセルフプロビジョニングと普遍のインフラの実現をどうするかということでした。
Opsチームはセルフサービスでプロビジョニングされた環境を保証しなくてはならないので、サポートのあるOpenShiftを採用しました。
自動化の促進
Jenkinsのパイプラインを活用して CI を実現し、QA環境でのテストが終わったらプロダクションにリリースできるようにしました。 しかし、プロダクションに持ち込むために、たくさんの承認プロセスがありましたが、これは時間を浪費する作業だったので、OpenShiftの中だけで済むようなコンポーネントのリリースは、承認プロセスを不要にしました。 ここまで自動化とプロセスの見直しを行いましたが、最後に残った課題は、リグレッションテストの自動化です。手動でのテストでは毎週のリリースには間に合わないので、テストツールを導入して自動化を可能としました。
まとめ
このプロジェクトを実施した結果、毎週のリリース時にサービスを止めることなく、ローリングアップデートが可能となりました。 サービスの提供環境としても、オートスケールの機能も活用して、アクセスが急激に増えた場合にも対応できるようになりました。
OpenShift の導入によって、リリースサイクルの短縮とサービス提供のSLAの向上が両方できた良い事例でした。