アプリケーション開発の変遷と解決の方向性〜コンテナ開発の時代～
デジタルトランスフォーメーション（DX）の実現をリードするのはIT環境であり、とりわけ顧客へのサービスなどに直接かかわる企業アプリケーションが成否を左右します。ところが、DXを前提とした企業アプリケーションの開発は、その歴史的な経緯も踏まえ一筋縄ではいかない状況にあります。
この記事では、DXを推進する上で取り組みが必須となる企業アプリケーションの開発について、その変遷と課題、解決の道筋となるマイクロサービスやコンテナについて紹介します。
ウォーターフォールモデル型の限界
企業アプリケーションは従来、上から下へと一方向で流れる滝をイメージした「ウォーターフォールモデル」で開発されてきました。ウォーターフォールモデルとは、システム開発の手順を模式化したもので、設計やプログラミングといった各段階を1つずつ順番に終わらせ、次の工程に進んでいく方式です。
工程や作業プロセスごとにチェック（検収）しやすいため、品質を重視する日本のシステム開発の現場、特に大規模なシステム開発プロジェクトにおいて、多く採用されてきた開発手法です。開発作業を進める中で、各工程に対応した品質保証が求められたり、各社独自の管理基準が定義されていたりするのが特徴です。
ウォーターフォールモデル型には、全体的な計画を立てやすい、タスク管理がしやすい、工数の見積もりがしやすい、エンジニアを集めやすい、工程終了時に検収できるなどのメリットがあります。一方で、「前工程に間違いがない」ことを前提または期待しているため途中での変更対応が難しい、変更が発生した場合の「手戻り」工数が増加する、モノリシックで巨大な作りのため特定の変更を実施する際の影響を見通せない、プロジェクト期間が長期に渡る場合があり採用技術が陳腐化してしまうなどの課題があります。
こうした課題は、高速性と柔軟な変更を重視する「DX的」な企業アプリケーションと相容れなくなってきています。問題を減らして安定稼働を目指すIT部門など従来型組織と、営業やマーケティング部門など顧客を意識してアプリケーションをより早く多くデプロイしたいと考える組織では、責任の捉え方が異なるため、合意した意思決定が難しいという側面も見えてきました。
図：ウォーターフォールモデルのイメージ
SOAとマイクロサービスの登場、変化への対応速度を上げる
ウォーターフォールモデルの課題を解決するため、新たな選択肢として2004年ごろから登場したのがSOA（サービス指向アーキテクチャー）です。さらに、ここ最近になり技術的にSOAの延長線上にあるアプリケーション開発手法「マイクロサービスアーキテクチャー」が登場しています。
SOAとマイクロサービスはともに、アプリケーションやその機能を「サービス」としてコンポーネント化し、部品として使えるようにし、それらのサービスを組み合わせることでさまざまな機能を利用できる設計手法です。
マイクロサービスではサービス同士をAPIで手軽につなぎ、ネットワーク経由で互いに通信するのが特徴です。身近なところでは、金融機関のスマートフォンアプリで複数の銀行口座の残高を参照できるものなどがあります。
APIを経由して各銀行とサービスを連携させたマイクロサービス型のアプリケーションであり、DXを実現する際の具体的な手法の1つと言えるでしょう。
アプリケーション実行環境に急速に活用が進むコンテナとは？
DXにおける1つの前提技術となるマイクロサービスアーキテクチャーでは、アプリケーションの実行環境としてコンテナを使うことが多くなっています。コンテナとは、複数のハードウェアでアプリケーションを柔軟に移動できる仮想化技術の1つと言えます。コンテナの最大の特徴は、環境を立ち上げ利用できるようになるまでの時間が非常に短いということでです。
図：仮想化とコンテナの違い
そして、このコンテナこそ、DXを実現するための切り札と言われています。導入企業は先端的なテクノロジーの採用に積極的なネット企業にとどまらず、メガバンクに広がるなど既に拡大に向けて動き出しています。
では、DX前提のコンテナ採用にはどんなメリットがあるのでしょうか。主なものとして3つを挙げます。
1つは開発生産性の大幅な向上です。コンテナは、アプリケーションとそれを実行するためのライブラリや設定情報などをまとめてコンテナイメージとして保持できます。例えば、実質的標準となっているDockerに準拠したものとしてコンテナイメージを作成すれば、ローカルの開発環境でも、クラウド上の試験環境や本番環境でも同じように動作します。どの環境にも持って行けるという意味で、可搬性が高いわけです。従来は実際のところ、「試験環境で問題がなかったのに、本番環境に移したらライブラリの微妙な違いで動作しない」といったことが課題になっていました。加えて、アプリケーション開発におけるCI/CD（継続的インテグレーション／継続的デリバリ）が実施しやすくなることも利点となってきます。
2つ目は、コンテナによる拡張性と可用性の向上です。前述のとおり、コンテナは環境の立ち上げが仮想マシンと比べて大幅に速いという特徴があります。そのため、キャンペーン開始時や自社がマスメディアで紹介されたときなど、トラフィックが急増してシステムへの負荷が高まった際に、すぐにコンテナを自動追加することで対応できます。障害が発生したケースでも、コンテナイメージから新たなコンテナを起動することですぐに復旧できます。ブランディングの機会を逃さないとう意味でも、あるいは障害によって企業としての信頼性を失うことを避けるという意味でも、柔軟なスケーリングは重要な機能と言えるでしょう。
3つ目はコスト削減です。コンテナでは、仮想サーバーよりもきめ細かくCPUやメモリなどのリソースをアプリケーションに割り当てられます。そのため、リソースを無駄なく有効に活用できるのです。また、1つ目で指摘した可搬性の高さから、より低コストでの運用が可能になるパブリッククラウド環境を選んで、すぐに移行するといった施策も採れます。2つ目で指摘した柔軟なスケーリング機能により、障害対応にかかる運用コストも減らすことが期待できます。
このようにコンテナには仮想マシンまでのアーキテクチャーでは難しかった機能が備わっています。ただし、コンテナのメリットを生かすには、複数クラウドを利用するマルチクラウドや、Kubernetesを中心としたコンテナ管理ソフトウェアなど、ベースとなる良質なインフラ環境が不可欠になります。