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