マイクロサービスを実践する
サーバレスとコンテナを比較、選定の決め手はアプリケーション特性
コンテナはリソースを節約し、導入時間を短縮し、マイクロサービスの優れたホストになる。それはサーバレスも同じだ。だが導入のオプションを見ると、両者には相似点よりも相違点の方が多い。
サーバレスコンピューティングは、アプリケーション導入の問題に対する完璧な解決策となるか、コストの高い大失敗につながるかのどちらかだ。仮想マシン(VM)、コンテナ、サーバレスアーキテクチャにはそれぞれ特有の長所と短所がある。だがサーバレスは、アプリケーションがその導入アーキテクチャに適さなければ、全てが機能しない恐れもある。IT部門の内部崩壊を防ぐには、開発者に十分な情報を与えた上で、新たな導入についてサーバレスとコンテナの比較を求める必要がある。
コンテナやサーバレスの適合性を判断するには、それぞれの種類のアーキテクチャが実現することや、各アーキテクチャがホストするアプリケーションのユーザーベースと、適切に導入するために必要なことを対比すべきだ。
本稿ではVMを検討の対象外とする。とはいえ、VMはIT部門が最もよく使用し、最も理解しているアプリケーションホスティングアーキテクチャだ。また、インフラを抽象化するアプローチとして最も一般的だが、複雑さとリソースのオーバーヘッドという代償を伴う。本稿では主にサーバレスとコンテナを比較する。サーバレスはリソース全体を抽象化する。これに対して、コンテナはOSの上位に配置される軽量かつ高速の分離層である。
併せて読みたいお薦め記事
コンテナ、サーバレスの特徴
マイクロサービスに取り組むには?
アプリケーションが必要とするもの
サーバレスクラウドコンピューティングには経済的メリットがある。企業は、アプリケーションの実行時のみ、コンピューティングリソースとアプリケーション実行の費用を負担すれば済む。アイドル時間にはコストがかからない。常に準備しておく必要はあるが常時実行されるわけではないアプリケーションやコンポーネントには、サーバレスが最適だ。
例えば、モノのインターネット(IoT)を使った農業用アプリケーションを考えてみよう。このアプリケーションは、湿度センサーを使って土壌の状態を計測する。土壌が乾燥していて水まきが必要だと分かるとイベントを生成する。これまで導入していたアプリケーションでは、雨の日は遊休状態になっていた。アクティブになるまで待機することで不要なリソースが消費される。コンテナシステムでは、アプリケーションが消費するリソースの量を節約できる可能性はある。だが、サーバレスコンピューティングを導入すれば、こうして節約したリソースをアイドル時間に消費することもなくなるだろう。アプリケーションのアイドル時間が長いほど、サーバレスの方が適切に思える。だが、そんなに単純な話だろうか。
いつものことだが、実際は印象よりももっと複雑だ。この例のIoTアプリケーションの場合、サーバレスアーキテクチャには数ミリ秒で利用準備が整うメリットもある。これに対して、コンテナシステムでは数十秒間の準備が必要になる。ただし、起動時間が長いコンテナを導入しても、IoTアプリケーションの目的実現能力に影響する可能性は低い。また、稼働時間よりもアイドル時間が長いアプリケーションなら必ず、コンテナよりもサーバレスの方が向いているというわけではない。サーバレスシステムのロジックは、コンテナシステムよりもコストがかかるだけでなく、技術的にも異なる。
サーバレスとコンテナのテクノロジーの比較
サーバレスについて細かく考えていくとしたら、次のような用語が関係してくるだろう。
- マイクロサービス……アプリケーションを分解した小さなコンポーネント。このコンポーネントは個別に拡張および導入可能
- ステートレス……前に使用したイベントのデータを使用も要求もしないアプリケーション
サーバレスクラウドコンピューティングは、コンテキストに依存しない処理を狙いとしている。つまり、ステートレスアプリケーションを対象とする。イベントに応じてサーバレスアプリケーションがアクティブになると、まず、過去のことを一切記憶していないコードが新たにコピーされる。イベントの中でも、そのイベント発生前のイベントや要求に依存するイベントはステートフルになる。より多くの作業に対処するためにサーバレスアーキテクチャの2つ目のコピーを起動することがある。その場合、2つ目のコピーは、1つ目のコピーが実行していたことを自動的には認識しない。
サーバレス導入でも、クライアント側やバックエンドで状態(ステート)を管理して、ステートフルアプリケーションを機能させることは可能だ。だが、こうした状態管理はアプリケーションのコードに組み込まなければならない。サードパーティー製のソフトウェアにそのようなオプションが存在する可能性は低いだろう。アプリケーションを社内で作成しているとしても、サーバレス導入にステートフルな動作を実装するには、複雑でコストの高い変更が必要になる可能性がある。
コンテナでは、コードに大きな変更を加えることなく、ほぼ全てのアプリケーションやアプリケーションコンポーネントを実行できる。これはサーバレスではできないことだ。大半のビジネスアプリケーションはトランザクション処理を実行し、その過程で1つ以上のデータベースを更新する。こうした処理は、ステートレスな動作にさらに多くの課題を突き付ける。トランザクションを処理するアプリケーションをステートレスにすると、複数のトランザクション間で衝突が起きる可能性がある。それぞれのトランザクションが販売と返品を報告すると、在庫や勘定残高に2つの問い合わせが行われ、それらが衝突した場合、在庫や貸借がゼロを下回る可能性がある。ステートレスな動作とトランザクション処理の動作を組み合わせるようにアプリケーションの設計を見直し、改良することはできる。だが、これは複雑なプロセスで、豊富な経験と多くの作業が必要になる。コンテナならこうしたことは要求されない。
現実と結び付ける
開発者がサーバレスとコンテナを調査する場合、アプリケーションにとって何が最適かを問うことになる。だが、それぞれの導入の懸念事項についても比較検討しなければならない。コンテナネットワークは曖昧さがなく、IPサブネットワークに基づいている。これは最も一般的なアプリケーション導入モデルだ。コンテナシステムはアプリケーション内のプライベートIPアドレス空間を使用する。ただし、管理者が公開するコンポーネントアドレスを選択できる。その結果、仮想プライベートネットワークまたはインターネット上で、ユーザーや他のアプリケーションにサービスを提供することが可能となる。サーバレスコンピューティングの場合、負荷分散やネットワークアドレス指定などの運用面は、サーバレスクラウドフレームワークが処理する。また、アプリケーションコンポーネントを従来型のクラウドやデータセンターでホストしている場合もあるだろう。その際にアプリケーションコンポーネントとサーバレスコンポーネントを統合するには、特別な手順を取らなければならない可能性がある。
コンテナでは長期的にホストする場所が必要になる。一方、サーバレスでは不要だ。コンテナは、アプリケーションやサービスにアクセスする多様なコミュニティーをサポートできる。しかも応答時間が優れている。ただし、地域ごとにコピーを導入することが条件になる。こうした導入モデルでは作業が分割され、さまざまなアプリケーションコピー間でアイドル時間が長くなり、コストが増加する。一方、サーバレスアプリケーションでは、利用可能なリソースがある場所ならどこでもワークロードのコピーを任意の数だけ実行できる。
マイクロサービスをホストする方法
マイクロサービスとは、分散アプリケーションコードの自己完結型コンポーネントで、個別に共有や拡張が可能だ。マイクロサービスはコンテナやサーバレスクラウドでの導入に適している。その差別化要素を突き詰めていくと、使用するマイクロサービスの種類の問題になる。マイクロサービスはステートレスなので、サーバレス導入に向いている。ただしマイクロサービスは、複数のアプリケーションが共有する汎用(はんよう)コンポーネントになることが多い。マイクロサービスが複数の異なるアプリケーションの構成要素になる場合は、コンテナでのホスティングの方がサーバレスよりも適切な導入オプションになる。サーバレスのマイクロサービスを定期的に使用すると、アプリケーションの応答時間が大幅に長くなる可能性がある。これは、サーバレスコンポーネントの導入がオンデマンドで要求されるためだ。
サーバレスは進化していくだろう。だが、サーバレスとコンテナには技術水準とコスト管理の水準の両面に明らかな違いがある。場合によっては、こうした違いにより、どちらか一方を選びがちになる。だが、アプリケーションを計画する担当者によっては混在モデルを採用しなければならないこともある。そうすることで、やや複雑さが増すとしてもだ。必ずしも万能な方法が存在するとは限らない。
Copyright © ITmedia, Inc. All Rights Reserved.
この記事の著者
関連記事
新着ホワイトペーパー PR
-
市場調査・トレンド
[コパード株式会社] 約9割が負担を実感 Salesforceのテスト業務に関する実態調査で見えた課題とは -
市場調査・トレンド
[コパード株式会社] 「Salesforce」開発・運用におけるAI活用実態調査レポート -
事例
[テクバン株式会社] 1画面でITサービスデスク業務が完結 太陽ホールディングスに学ぶデバイス管理 -
製品資料
[デジタルサーカス株式会社] ライセンス無料 Drupalベースの「多言語ECサイト開発用パッケージ」の実力は? -
製品資料
[デジタルサーカス株式会社] 日本発グローバル企業用Drupal「Risley(リズリー)」の実力とは?
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
半数がブルーカラー転向を視野に? ベテランエンジニアを追い込む“54歳の壁”
-
2
法務と開発者で「言葉が通じない」問題 トヨタやソニーが語るOSS管理の真実
-
3
なぜ「Gemini 4 Argon」は出遅れたのか? Googleが狙う“逆転のシナリオ”
-
4
「レガシーシステム・老朽化システムの運用課題と刷新」に関するアンケート
-
5
脱VMwareか、継続か? 仮想化ソフト主要6製品の運用管理と統制機能を徹底比較
-
6
ChatGPTは“検索しまくり”でGeminiは“淡泊”? データが明かすAIの裏側
-
7
なぜ「全社配布Copilot」は使われないのか? 失敗に学ぶAI定着
-
8
1回で分かる:仮想マシンを丸ごとバックアップする「VADP」の仕組み
-
9
「企業内サーバ環境の利用実態」に関するアンケート
-
10
セキュリティは「情シス任せ」が過半数 漏えい発生時やSCS評価制度の課題は?
ホワイトペーパーランキング PR
-
1
家庭用Wi-Fiルーターの業務利用は危険? 避けるべき理由と具体的な対策
-
2
システムの保守がモダン化を阻む? 「変えない判断」から脱却する方法とは
-
3
不審メールの経路や見せ方に変化? 2026年夏の3事例から見えた動向と対処方法
-
4
AI駆動攻撃にどう対抗する? 超速の攻撃からエンドポイントを保護する方法
-
5
なぜRPA導入は頓挫する? シナリオ作成の壁を乗り越える解決策とは
-
6
プログラミング不要で誰でも実現できる、ネットワーク運用管理の自動化とは
-
7
東大教授と考える、AI時代の「データ主権」「信頼性」「ガバナンス」の在り方
-
8
Linux初心者でも知らないとまずい「RHEL」「SLES」の違いとは?
-
9
最速72分でデータが流出? 最新の脅威トレンドや侵入手法から分かった防衛策
-
10
生成AIの活用を阻む「5つの壁」とは? AIネイティブ組織へ変革を遂げる方法
TechTargetジャパン SNS
インフォメーション
注目情報をチェック
TechTargetジャパンをフォロー