システム開発のモダナイズ、パート 1-モダンアプリケーション

私はエンタープライズストラテジストとして、企業がビジネスの俊敏性を生み出すために採用している最新のプラクティスとテクニックについて、時間をかけて顧客と話し合ってきました。その実践方法やテクニックは、今日の「モダンアプリケーション」の基礎でもあります。 しかし、開発者やリーダーのために「モダンアプリケーション」を定義することが、1つの非常に重要な理由から難しい場合があります。その理由とは「モダンアプリケーション」が実在する物ではないからです。モダンアプリケーションとは、開発者が活用可能な最新のテクニックとテクノロジーに基づいてアプリケーションを構築するためのアプローチなのです。

Werner Vogels 氏は、アマゾンのモダナイゼーションの道のりと、企業がモダンアプリケーションを構築することが「ビジネスの定義により多くの時間を費やし、ピーク時の顧客需要に容易に対応できるようにシステムをスケールアップし、俊敏性を高め、新しい機能をより速く、より頻繁に市場に投入している」ことを概説しました。振り返ると、アジャイルマニフェストは2001年2月に初めて発表され、[1] AWSは2006年に設立され、DevOpsという用語は2009年に生まれ、[2]私が2005年にCIGNAで働いていた時には、我々はIBMなどのサポート製品を使いサービス指向のアーキテクチャを構築していました。ほとんどの企業は、長年にわたってモノリシック・アプリケーションを構築しており、それが新しいプラクティスやテクノロジーを大規模に採用しようとする際の困難の原因になっています。それなのに、なぜ我々はまだモノリスを構築し、維持しているのでしょうか？

当時は、モノリスを構築する理由はたくさんありました。シンプルで互いに接続されたビルディングブロックがないので、新しいアプリケーションの構築は困難で時間がかかりました。新しいアプリケーションのフレームワークを組み立て、基盤となるインフラストラクチャの用意し、監視と運用手順を整備するには多大な作業が必要でした。開発チームと運用チームはすでに既存のアプリケーションに精通していたので、モノリスに多くの機能を組み込む方が簡単でした。この様な理由から、私たちは長い間モノリスを構築し続けており、モノリスから離れるためにさらに多くの時間をかけています。

これらの大規模で緊密に結合されたアプリケーションは、多くの機能を提供し、その基盤の上で構築を続けることを容易にするアーキテクチャでした。しかし、それを成長させ強化する事で、肥大化、技術的負債、相互依存をもたらし、結果的に私たちの変化への対応は鈍く、困難なものになりました。ウォーターフォールソフトウェア開発 [3] の方法論は、このパラダイムに向いています。なぜなら、すべてのパーツが最終的にまとまることを保証するために、事前に多くの計画を立てる必要があるからです。しかし、大きな範囲で多くの変更が発生するため、計画どおりにいかないことがよくありました…そのときはマニュアルプロセスに切り替えて、ヒーローの出番です。

現在、私たちはそれとは違う世界に住んでいます。クラウドテクノロジーによって継続的に成長し、形作られてゆく世界です。これらのテクノロジーは、私たちがどの様にシステムを構築するか、どの様にチームを編成するか、チームが何を所有するか、どれくらいビジネスに影響を与えるか、を変化させるビルディングブロックを提供します。これが、私や多くのリーダーが、アジャイル、DevOps、クラウド・トランスフォーメーションを統合戦略として結びつける理由です。

今日のモダンアプリケーションは、明日には大きく変わっている可能性がありますが、過去とは違う、次の様なアプローチで構築されています。

1. スコープを縮小する
2. 仕事に適したツールを選択する
3. 差別化につながらない部分をオフロードする
4. ビルディングブロックを接続する
5. すべてを自動化する

スコープを縮小する

マイクロサービスパターンは何年も前から存在し、分離されたサービスをどのように作成するのが最善かという私たちの業界における考え方の進化を反映しています。しかし、「マイクロ」という名前にだまされないでください。サービスのサイズは重要ですが、小規模なチームが所有して運用できること、独立したスケールとデプロイが可能な機能単位を構築することがより重要です。マイクロサービスパターンは、トランスフォーメーションや「モダンアプリケーション」において重要です。 独立したスケーラビリティと再利用性という利点に加えて、アジャイルや DevOps とも相性が良いです。オーナーシップと自律性を持つという考え方は、生産性が高く、成功している「自分で開発し、運用する」アジャイルチームの重要な特徴です。

自律性を促すには、全てにおいて摩擦を減らさなければなりません。我々の速度を鈍らせる多くの手法は、人やソフトウェアが誤って他の変更と競合するのを防ぐため存在します。しかし、これらのプラクティスによって、我々は頻繁な変更を避け、大きな変更セットを生み出し、より広範囲の調整が必要になります。この様にして防ごうとしているコンフリクトは、コードベース、リリースの調整と実行、本番環境の操作、および優先順位付けで発生します。これらのコンフリクトを解消する良い方法は、分割することです。そして、分割され独立した単位であっても、単独で価値を提供できるようにすることです。

マイクロサービスパターンはまさにこれを実現し、最終的には変更の範囲を管理可能なサイズに縮小することができます。マイクロサービスを導入すると、システムは全体として複雑になる可能性が高いですが、各コンポーネントの変更管理と運用が容易になります。このパターンをアジャイルやDevOpsと組み合わせることで、俊敏性を高め、障害の影響を軽減することで、そこからより早く安全に学習することができます。

仕事に適したツールを選択する

当時利用可能だった技術や多くの理由から、私たちはあらゆる問題を解決するためにリレーショナルデータベースを使用していました。ハンマーを手にすると、すべてが釘のように見えました。これはデータベースだけに限ったことではありません。Dealer.comでは、フル機能の分散キャッシュであるTangosol Coherence（現在のOracle Coherence）を使用しました。インメモリキャッシング、ライトビハインドキャッシング、さらにはキューイングなど、あらゆる用途に使用しました。はい、キューイングもです。そして、それはしばらくの間は、うまくいきましたが、今日では違います。 Wernerが議論しているように、ビルダーには選択肢があります。

マイクロサービスによってスコープを縮小し、分離することで、開発者が直面している問題に対して最も適切な、目的に合わせて構築されたソリューションを選択できるようになりました。それにより、システムのすべてのレベルでソリューションを最適化でき、その中の小さな機能の特定のニーズに基づいてスケールすることができます。適切なツールを選択することで、ソリューションの構築と運用方法をより具体的かつ意図的に選択することができます。

オフロードと接続

開発者は仕事に適したツールを選択できるようになったため、モダンアプリケーションは新しい形をとり、問題を解決するために必要なロジックやオペレーションは少なくなりました。しかし、選択をする際には、できるだけ多くの差別化につながらない作業(undifferentiated work)をオフロードすることが重要です。これまで、開発者は、新しいテクノロジーの探索、フレームワークの設定と調整、問題を適切に解決するための基盤の操作方法を学ぶ事にかなりの時間を費やしていました。その結果、複雑な環境では、運用とトラブルシューティングが困難でした。多くの場合、これらのアプリケーションは、様々なプロバイダーからの、異なるレベルの管理、運用のサポート、ツールを組み合わせて構築されていました。

フルマネージドサービスとサーバーレスサービスにより、モダンアプリケーションは、ミドルウェア/基盤の運用と管理の負荷を軽減し、他のクラウドサービスとの接続もすぐ行うことができます。クラウドプロバイダーは、これらのサービスの改善、運用、およびセキュリティ保護といった重要な作業、つまりビルディングブロックに対して責任を負います。これにより、アプリケーションの所有者はビジネスロジックに集中し、これらのサービスを接続して意味のあるソリューションを構築できます。AWS Lambda や AWS Fargate などのサービスを選択することで、開発者はコードがどこで実行されるか、負荷を処理するのに十分な容量があるかどうか、どうやってフリートを作成して管理するか、などを考慮する必要がなくなります。開発者は、ビジネスロジックを記述し、弾力性とセキュリティとともにコンピューティングとメモリのニーズを設定した上で、監視、運用を行い、開発のイテレーションを回すことができます。

すべてを自動化する

AWS は、簡単に接続できるサービスを構築しているため、さまざまなワークロードの処理、イベント処理への対応、ストリーミングデータからの洞察の獲得、機械学習によるインテリジェントなアプリケーションの作成を容易にします。しかし、もう 1 つの利点は、これらのサービスが API を提供していることで、プログラムでそれらと対話し、操作やデプロイを自動化できることです。これにより、機能のデプロイとテストだけでなく、インフラストラクチャとセキュリティを含む CI/CD パイプラインを構築できるようになりました。 Werner によると、自動リリースパイプラインにより、Amazon は「エラーを最小限に抑えながら、多くのコードを迅速にテストしてリリースする」ことができています。

リリースパイプラインの自動化に加えて、自動化はチームの作業負荷をオフロードし、タスク実行の一貫性とスピードが向上させます。自動的なシステム修復や脅威検出によってシステムの回復力を向上させることにより、ビジネス価値に集中する機会も提供します。システムのあらゆる側面を自動化することで、デプロイの頻度を大幅に増やし、変更のリードタイムを短縮し、平均復旧時間を短縮し、変更の失敗率を減らすことができます。 調査によると、これらの指標を改善することで、チームのパフォーマンスが向上し、ビジネスへの価値の提供がより頻繁に行われることがわかっています。

モダンアプリケーションは、これらの技術とテクノロジーを組み合わせて、障害を最小限に抑え、時間を短縮しながら、ビジネス価値の提供を最大化します。この俊敏性はビジネスを変え、新しいイノベーションの扉を開いています。ワクワクする時代です！もっと開発を！モダンに構築しましょう！

どの様に最初の一歩を踏み出すかを知りたい方は、こちらのパート2を読んでください。

ブライアン・ランダーマン
エンタープライズストラテジスト & エバンジェリスト @ AWS
@bryanlanderman
brylando@amazon.com

[1] — https://agilemanifesto.org/history.html
[2] — https://theagileadmin.com/what-is-devops/
[3] — ウォーターフォールソフトウェア開発の基本的な定義はこちらです:https://www.lucidchart.com/blog/waterfall-project-management-methodology

著者について

ブライアン・ランダーマン

ブライアン・ランダーマン は 2019 年 2 月にエンタープライズストラテジストおよびエバンジェリストとして AWS に入社しました。この役割において、ブライアンは企業のエグゼクティブと協力して、クラウドがスピードと俊敏性を高めながら、より多くのリソースを顧客に捧げるのに役立つ方法についての経験と戦略を共有しています。AWS に入社する前は、ブライアンはコックスオートモーティブのCTO でした。

翻訳は Solutions Architect 多田が担当しました。原文はこちらです。