DevOpsは、アプリケーションを開発して公開し、サポートからのフィードバックを反映していく方法として主流になりつつあります。しかし、DevOpsを成功に導くには、組織面での複雑さやマシンデータの収集といった課題を克服する必要があります。
マイクロサービスとは、マイクロサービスアーキテクチャとも呼び、ソフトウェア開発アプローチの1つです。アプリケーションを一枚岩の「モノリシック」なプログラムとしてではなく、複数のサービスや機能を疎結合させて構築します。
マイクロサービスのアーキテクチャでは、大規模で複雑なアプリケーションを提供する際のスピードと信頼性が向上します。何をもってマイクロサービスと呼ぶのでしょうか?マイクロサービスであるかどうかは、コーディング手法ではなく、それがどのように大規模なシステムやソリューションの一部となっているかによって決まります。マイクロサービスは、通常、狭い範囲に適用され、小さなタスクに特化しています。
マイクロサービスは以下のような特徴があります。
マイクロサービスはサービス指向のアーキテクチャの一形態ですが、一般にサービス指向アーキテクチャ(SOA)よりも安定性と柔軟性が高く、開発が容易です。
これまで、ソフトウェアシステムのほとんどが、一枚岩のモノリシックなアプリケーションとして構築されてきました。コンポーネントが疎結合されているマイクロサービスやサービス指向のアーキテクチャとは対照的に、モノリシックなアプリケーションではコンポーネントと機能は密結合されています。モノリシックなアプローチには以下のようなデメリットがあります。
マイクロサービスは、従来のモノリシックなシステムよりも優れた柔軟性を提供します。マイクロサービス開発には決まった1つの方法があるわけではありませんが、マイクロサービスアーキテクチャにおけるデータ管理については一般的なガイドラインがあります。開発チームの関心がマイクロサービスに向く背景には、以下のような理由からデータ管理が複雑になっているという事情があります。
しかし、最大の違いはそのサイズです。モノリシックアーキテクチャではサイズが大きすぎて、変更や導入、拡張を行えないことが少なくありません。その点、マイクロサービスアーキテクチャは柔軟に対応することができます。
SOAは、多種多様なアプリケーションとの統合を必要とする大規模で複雑なビジネスアプリケーション環境に適しています。それに対し、マイクロサービスは、開発者がコントロールしやすい、より小規模で細分化されたWebベースのシステムに適しています。つまり、構築するアプリケーションの規模によって使い分ける、といった違いがあるのです。アプリケーションを小さな部品に分割することは新しい概念ではなく、マイクロサービス以前にもサービス指向アーキテクチャ(SOA)ですでに取り入れられていました。
SOAマニフェストでは以下を提唱しています。
マイクロサービスはIT部門で起きたDevOps文化への移行の一端です。DevOpsでは開発チームと運用チームが緊密に連携しながら、ライフサイクル全体にわたってアプリケーションをサポートしていきます。すでにSOA文化が浸透している企業では、マイクロサービスの導入を検討すべきです。
本質的にサービス指向のアーキテクチャ(SOA)とは、相互に通信する複数のサービスの集合体です。通信は、単純なデータの受け渡しであることもあれば、何らかのアクティビティを協調的に行う2つ以上のサービスが関与することもあります。
サービス指向のアーキテクチャ(SOA)は、アジャイルの高速な開発サイクルでは効果的な戦略です。マイクロサービスを採用するメリットは、主に開発者が継続的デリバリーサイクルを導入できるという点にあります。マイクロサービスを採用する前に、まずはすでに利用しているテクノロジーを評価する必要があります。どちらのアーキテクチャのパフォーマンスが高いかではなく、構築しようとしているアプリケーションの目的を評価することが重要なのです。
コンテナは、Linuxのプログラムやプロセスをパッケージ化し、導入し、実行するための手法です。1つの巨大なモノリシックアプリケーションをコンテナとして持つこともできれば、コンテナをまったく使わないマイクロサービスでアプリケーションを構成することもできます。
コンテナはリソース割り当てを得意としており、DevOpsで好まれます。マイクロサービスはソフトウェア設計パターンであり、開発者に好まれます。コンテナとマイクロサービスはどちらも有用であり、併用できますが、相互に依存関係はありません。これがマイクロサービスとコンテナの違いです。
マイクロサービスのアプローチでは主に2つの課題があります。相互に自立したチームがそれぞれチームごとに異なる作業スタイルを持つという点と、いつまでたっても「終わった」と感じられないという点です。最初の課題は、マイクロサービスによって生産性の向上やよりよいツール選択が可能になるにもかかわらず、しばしば各チームが別のコーディング言語、フレームワーク、ライブラリを選びたがるというものです。このようなかたちの自立に慣れていないチームは行き詰まってしまうかもしれません。
2つ目の課題は、モノリシックアーキテクチャでは変更そのものが大きな1つのプロジェクトとなり、そのプロジェクトに明確な始まりと終わりがある一方、マイクロサービスでは変更は常に行われるという点です。頻繁な変更は悪いことではなく、システムを進化させるために欠かせない特性の1つなのです。しかし、このようなフローになじみのないチームは適応するための努力が必要になるかもしれません。
さらに、もう1つの課題として、マイクロサービスには複雑さがあり、戦略的なアプローチで監視を行う必要があります。
マイクロサービスへの切り替えが進む背景には、イノベーションが加速する中、企業がビジネス上の優先事項に集中的に取り組もうとしていることがあります。同様に、スピードと成果を重視するDevOpsの広がりも、マイクロサービスへの関心に拍車をかけています。
Amazon、Spotify、Uber、Groupon、Karmaなど、多くの企業がモノリシックアーキテクチャからマイクロサービス構造へとシステムを進化させてきました。Netflix社の開発者はマイクロサービスを使用して、毎日数千ものコードセクションをデプロイし、1億3,900万人の契約者と100億時間に及ぶ映画やTVドラマシリーズをサポートしています。
マイクロサービスは、ソフトウェアの開発と導入を迅速に行えるため、コストを節約し、企業の競争力を高めることができます。開発時点でアプリケーションがどのようなデバイスで実行されるか予測できない場合、マイクロサービスアーキテクチャは最適な選択です。開発者は、アプリケーションの速度を低下させたり停止させることなく、制御しながら迅速にアップグレードすることができます。その他にも以下のメリットがあります。
監視は、マイクロサービスアーキテクチャにとって極めて重要な要素です。アプリケーションをコンポーネントに分割するマイクロサービスは、多くのメリットをもたらす一方、複雑化を招きます。マイクロサービスは相互に通信する必要があり、さらに、個別に作成、更新される各コンポーネントと他のコンポーネントを連携させる必要もあります。そして、これらの通信や連携は最小限の遅延で行う必要があります。つまり、マイクロサービスで構成されるアプリケーションの管理とは、相関するコンポーネントからなるネットワークを管理することを意味します。全体の信頼性を確保するには、ネットワークを効果的に管理することが不可欠です。
監視とオブザーバビリティは、DevOpsやアジャイルの考え方を身につけている開発者にはおなじみかもしれません。マイクロサービスを成功させるには、これらのアプローチとともに、SDLC(ソフトウェア開発ライフサイクル)のあらゆる段階で自動化とコラボレーションを実現する必要があります。構成管理、CI/CDサーバー、APM、ネットワーク監視、ダッシュボード、自動アラート、インシデント管理は、マイクロサービスを実行するチームにとっての基盤です。
マイクロサービス監視には、基本的な監視と、迅速なアプリケーションデプロイという2つの要素が不可欠です。
これらを実現するためには、DevOps文化に見られるような開発者と運用者の緊密な連携という重要な転換が組織に求められます。プロビジョニングとデプロイを迅速に行うには、このような連携が必須です。監視で問題が見つかった場合に速やかに対応できるようにしておくことも重要です。
分散したシステムでは、より効果的なオーケストレーション、負荷分散、障害分離など、さまざまなチームがオブザーバビリティの文化の確立に向けて協力していくことが可能になります。
もちろん監視は、マイクロサービスアーキテクチャを維持するために最優先で実行する必要があり、異常が発見された場合にも対応が必要です。迅速かつ効果的に対応するには、アラートプロセスとインシデント対応計画を策定しておくことが重要になります。
DevOps 5つのプラクティス
DevOpsチームの明暗を分ける5つのプラクティスについてご紹介します。
DevOpsは、アプリケーションを開発して公開し、サポートからのフィードバックを反映していく方法として主流になりつつあります。しかし、DevOpsを成功に導くには、組織面での複雑さやマシンデータの収集といった課題を克服する必要があります。
DevOps Dozen2 Awardsで最優秀電子書籍賞を受賞しました。オブザーバビリティとは何か、単なる監視とは何が違うのかについてご紹介します。
Splunkプラットフォームは、データを行動へとつなげる際に立ちはだかる障壁を取り除いて、オブザーバビリティチーム、IT運用チーム、セキュリティチームの能力を引き出し、組織のセキュリティ、レジリエンス(回復力)、イノベーションを強化します。
Splunkは、2003年に設立され、世界の21の地域で事業を展開し、7,500人以上の従業員が働くグローバル企業です。取得した特許数は850を超え、あらゆる環境間でデータを共有できるオープンで拡張性の高いプラットフォームを提供しています。Splunkプラットフォームを使用すれば、組織内のすべてのサービス間通信やビジネスプロセスをエンドツーエンドで可視化し、コンテキスト(把握したい要素) に基づいて状況を把握できます。Splunkなら、強力なデータ基盤の構築が可能です。
日本支社を2012年2月に開設し、東京の丸の内・大手町、大阪および名古屋にオフィスを構えており、すでに多くの日本企業にもご利用いただいています。
© 2005 - 2023 Splunk Inc. 無断複写・転載を禁じます。