NCDCのマーケティング担当、播磨です。
先日、AWS Builders Online SeriesというAWSが提供するコンテンツでコンテナ、サーバーレス、マイクロサービスなどについて学ばせてもらいました。
僕自身はエンジニアではないのですが「AWS初心者向け16セッション」はとてもわかりやすい内容で、NCDCのサービスをお客さまに説明する際にも役立ちそうだったので、学んだことをこの記事にまとめてみます（AWS Builders Online Seriesの内容そのままではなく、かなり要約したり独自の視点も加えたりしてアレンジしています）。
なお、元ネタであるAWS Builders Online Seriesの説明（下記）にもあるとおり、本記事は、どちらかといえば「基礎」の話で初心者や非エンジニア向けのコンテンツです。
AWS Builders Online Series は基礎コンテンツのみで構成され、約 3.5 時間で集中的に学習できる、グローバルでも人気のイベントです。ゼロから AWS を知りたい方や、機械学習、コンテナ、サーバーレス、マイクロサービスアーキテクチャなど話題の技術を基礎から学びたい方は是非ご登録ください。
目次
IT領域のイノベーションが起こすビジネスモデルの変革
テーマは「モダンアプリケーション」なので、もちろんゴールはIT領域の話になるのですが、まず「ビジネスにおいてなぜそれが大切なのか？」の解説です。
近年、さまざまな業界でITを駆使した新興企業がグローバルなリーダーに駆け上がる事例が起きています。
AWS Builders Online Seriesでは具体例として下記のものが挙げられていました。
Amazonが書店のあり方を再定義し、出版業界を変革した。
airbnbが宿泊サービスのあり方を再定義し、ホテル業界を変革した…。
これらは、新興企業がITを駆使してイノベーションを起こし、ビジネスモデルそのものを変えてしまった例だといえます。
では、Amazonやairbnbのようなビジネスの変革者となるために、何をすればいいのか？
もちろん、イノベーションの起こし方に唯一無二の正解なんかはありませんが、成功した企業の多くに共通するものがあります。
それは、市場に対して新しい技術やアイデアをスピーディーにリリースし、市場（エンドユーザー）からのフィードバックを得て傾聴し、また新しいアイデアを生み出してはリリースする…。このサイクルをできるだけ早く回すという考え方です。
いわば実験を繰り返していくことでイノベーションを実現するのです。
システム変革の柔軟性がイノベーションにつながる
ここから少しIT領域の話に入ります。
下図はAWS Builders Online Seriesから引用した「企業におけるIT変革のスペクトラム」で、横軸は変革の頻度を、縦軸は変化の大きさを示しています。
安定あるいは変化しないことを基本としている企業（多くの大企業）は変化の波が緩やかな左側に位置します。変化し続けることが当たり前と捉え、スピード重視で自らが市場の潮流を変えたいと考える企業（新興企業）は波が激しい右側に位置しているといえます。
結論からいえば、右側の「変化し続けることが当たり前」という考えの方がイノベーションを起こしやすいのですが、先になぜ「変化しないことを基本」とした考え方ではそれが難しいのかを説明します。
従来型の企業システムが抱える問題
変化の頻度が低いシステムは一度決めたことの変更が難しくなるため、慎重に計画を立てることが求められます。多くの場合、時間をかけて要件を収集し、いくつものビジネスケースを検討して、大きなスケールのプロジェクトを作りがちです。
そうしたプロジェクトは複数年にわたるような長期計画が必要で、多額のコストもかかるので変革のスピードは緩やかにならざるを得ません。
事前計画だけで数ヶ月や長いと数年をかけて要件の収集を行うことも珍しくないようですが、その際に必要以上に（あったらいいな程度の）要望まで収集してしまう傾向があるため、スコープが肥大化するリスクもあります（肥大化すれば当然リリースがさらに遅くなる）。
もちろんシステムの特性にもよるので、慎重に長期間検討するアプローチがすべて間違いということはないですが、この方法だとリリース頻度はどうしても少なくなります。そのため、検討しているうちに同業他社が先行サービスをリリースするなどして遅れを取るリスクがあります。
また、大きなプロジェクトでは計画の後半になってからセキュリティや信頼性の問題が発覚すると影響範囲が大きく広がり、修正のための期間やコストが一気に膨れ上がるリスクもあります。
結果として、著しい環境の変化がある昨今の市場において、大掛かりなプロジェクトではイノベーションを生み出すことは難しいといえるのです。
イノベーションを起こす企業のやり方
一方で、イノベーションを起こしうる企業は実験を大切にしているので、成功するとは限らないアイデアでも素早くサービス化してリリースし、早くフィードバックを得て改善を繰り返す方法をとります。
そのため、それに適した小さなシステムを設計し（後で出てきますが、設計の思想として「マイクロサービス」というものがあります）、高頻度で少しずつ機能をリリースしていきます。
小さなシステムなので、開発計画の長期化や、スコープの肥大化・セキュリティ等の問題でリリースが遅れるリスクは抑えることができます。
従来型とモダンなシステムの比較
一旦、ここまでの説明を「従来型とモダンなシステムの比較」というかたちで整理します。
もちろん「モダン」が「イノベーションを起こす企業のやり方」にあたります。
システムの大きさ
- 従来型：ひとかたまりの大きなシステムをつくる（大きいが故にさらに肥大化しがち）
- モダン：小さなシステムを積み上げるアプローチでつくる
開発の規模
- 従来型：⼤規模投資と⻑期化する開発
- モダン：ひとつひとつの開発のサイズを縮⼩しリリース頻度を増やす
意思決定のあり方
- 従来型：トップダウン型の意思決定
- モダン：実験で得た反応の測定によるデータ重視型の意思決定
ポイントは「小さく素早く柔軟に！」
ひとつひとつを小さく素早く市場にリリースすると、データ（ユーザーの反応）を早く蓄積できます。データをもとに優先度や妥当性を検証する適切な意思決定プロセスを実現できることもモダンなシステムの特長といえます。
市場のニーズは絶えず変わるので、柔軟にシステムを対応させていく（小さい単位でリリースしていく）ことが重要なのです。
ライフサイクル
- 従来型：できるだけ変えずに保護する
- モダン：継続的なリファクタリングと改善を行う
セキュリティ
- 従来型：ベストケースの実⾏状態に向けた計画を立てる
- モダン：攻撃及び障害を予め想定しておく
ポイントは「変更を見据えた設計」
大きく多機能なシステムは、その代償として少しの変更でも他の部分への影響が生じる恐れがあるため、完成後は「できるだけ変えない」ことが重視されがちです。一方でモダンなシステムは最初から継続的な変更を行うことを意図した設計をしておきます。
セキュリティ面においても、従来は「完璧に守れる」というベストケースに基づいた設計をしていましたが、モダンなシステムでは「攻撃や障害は常に起こりうる」という前提で、問題が起きた時にどう対処するのかを重視するDesign for Failureな考え方をとるという違いがあります。
ITとビジネスの関係
- 従来型：ITとビジネスが分断している
- モダン：ITとビジネスが1チーム
ポイントは「ITとビジネスの密接な関わり」
アイデアを素早くサービス化してリリースし、市場のフィードバックをすぐ改善に活かす。こうした取り組みのためにはITとビジネスが常に密接に関わっている必要があります。
ビジネスを理解している人と開発や運用がわかる人をひとつのチームにすることや、ビジネスと技術の橋渡しをするプロセスをつくっておくことが大切です。
モダンアプリケーションに求められるもの
長くなりましたが、ここでやっとモダンアプリケーションの説明になります。
ITシステムはインフラ（ネットワーク、サーバ、データベース、OSなど）と、その上で動くアプリケーションで構成されますが、アプリケーションの部分で、先述した「モダン」なシステムの実現に貢献するのがモダンアプリケーションです。
AWS Builders Online Seriesでは、下の項目がモダンアプリケーションに求められる能力として挙げられていました。
- Secure（安全性）：セキュリティの高いガバナンスの効いたシステムであること
- Resilient（弾力性）：システムのコンポーネントの一部にたとえ障害が起きたとしても全体を落とすのではなく、一部機能を低下させながらシステム自体は継続して運用できる弾力性を持つこと
- Elastic（伸縮性）：予期せぬリクエストの増加が起きた時でもシステムがそれに応じて自動的にスケールして対応すること。一方でリクエストが落ち着いたら自動的に縮小してコストを抑える伸縮性
- Modular（モジュラー化）：個々のモジュールは独立してデプロイすることができて、それぞれは自律的に動作するように構成。それらが有機的に繋がってシステム全体を成す
- Automated（自動化）：たとえばCI/CDに代表されるような自動化されたプロセスや、リリース後の監視、問題に対するアラートの発信、適切な対応の自動化など、必要な作業は自動化することで一番価値のあるビジネスロジックに集中できるようにする
- Interoperable（相互運用性）：各サービスはAPIで会話する。自律的に動作しながらも有機的に相互運用が可能な構造
なぜクラウドネイティブか？
ここまで、次の２点について説明してきました。
- ITを駆使したイノベーションがビジネスの勝者となるための重要な要素である
- イノベーションを可能にするためには、変化し続けることを前提に設計されたモダンなシステムが必要である
この記事のタイトルは「なぜクラウドネイティブなモダンアプリケーションが必要なのか？」なのですが、まだ「クラウドネイティブ」の話がまったく出てきていないので、最後にこの部分を説明します。
以前はITシステムのインフラ調達や管理は自社で行うものでしたが、クラウドサービスの発展により、インフラの調達、管理をクラウドベンダーに任せることができるようになりました。
クラウドを上手に活用すれば、弾力性、伸縮性、自動化など、先に挙げた「モダンアプリケーションに求められる能力」が容易に得られるようになってきたのです。
つまりクラウドを前提としたアプリケーション設計を行うことがモダンアプリケーションの実現につながるといえます。このような構成を「クラウドネイティブ」と呼びます。
クラウドネイティブという言葉はさまざまな意味で使われており正確な定義はないのですが、AWS Builders Online Seriesでは「クラウドネイティブなモダンアプリケーションの定義」をこのように説明していました。
クラウドが提供する様々なサービスを利⽤して、セキュリティーを担保しガバナンスや統制を保ちつつも、素早く、頻繁に機能をリリースすることが可能で、スケーラビリティーや弾⼒性、可⽤性に優れ、疎結合でイベント駆動なアーキテクチャを持ち、観測性、障害対応性に優れているアプリケーション
NCDCではもう少し簡単に、次のような説明をすることが多いです。
クラウドネイティブとは、コンテナ、サーバレスなどの技術、クラウドベンダーが提供するマネージドサービスを積極的に利用し、それらを使用する前提の設計、開発を行うこと。
モダンなシステムに用いられるマイクロサービス
こうしたクラウドネイティブなモダンアプリケーションを実現する手法として、よく「マイクロサービスアーキテクチャ」が選択されます。
マイクロサービスとは、複数の規模の小さなサービスを組み合わせてひとつの大きなアプリケーションを構成する、ソフトウェア開発の技法のひとつです。
従来は「すべての機能がまとまったひとつの大きな塊」としてソフトウェアを設計することが多かったのに対し、マイクロサービスは「まず機能を分解していき小さなサービスをつくる。それらを組み合わることでひとつの大きなソフトウェアを構成する」という考え方です。
この記事の参考にさせていただいたAWS Builders Online Seriesの「AWS 基盤上でマイクロサービス/ドメイン駆動設計って、結局何をどうすることなのか」というセッションでは、タイトルにあるとおりマイクロサービスやドメイン駆動設計の説明も出てきたのですが、そこまでをひとつの記事にするととても長くなるので、それはまた別の機会にまとめたいと思います。
なお、マイクロサービスについてはこの記事と同じく初心者向けに詳しく説明した過去記事もあるので、併せてご覧ください。
マイクロサービスとは？ そのメリットを簡単に解説（初心者・非エンジニア向け）
豊富な実績があるNCDCの技術コンサルティング
いかがでしょうか。初心者にも「なぜクラウドネイティブなモダンアプリケーションが必要なのか？」が理解しやすい説明になっているといいのですが…。
NCDCでは、マイクロサービスの導入支援をはじめ、アーキテクチャの設計コンサルティングや新しい技術を取り入れるための技術コンサルティングを行っています。システムのモダナイズでお悩みの方はぜひ一度ご相談ください。
AWSの導入とマクロサービスの積極活用でクラウドネイティブ化に取り組んだ事例や、マイクロサービスを活用するためのAPI設計標準化の事例など、豊富な実績がありますのできっとお役に立てると思います。
実際にマイクロサービスを取り入れた下記の事例記事も参考になると思いますので、併せてご覧ください。
システムアーキテクチャの刷新とアジャイルの導入で、ビジネス要求への迅速な対応を実現
※この記事は、AWS Builders Online Seriesの「AWS 基盤上でマイクロサービス/ドメイン駆動設計って、結局何をどうすることなのか」というセッションの中から「なぜクラウドネイティブなモダンアプリケーションが必要なのか？」という説明にフォーカスして参照させていただいています。
