マイクロサービスを実践する
サーバレスとコンテナを比較、選定の決め手はアプリケーション特性
コンテナはリソースを節約し、導入時間を短縮し、マイクロサービスの優れたホストになる。それはサーバレスも同じだ。だが導入のオプションを見ると、両者には相似点よりも相違点の方が多い。
サーバレスコンピューティングは、アプリケーション導入の問題に対する完璧な解決策となるか、コストの高い大失敗につながるかのどちらかだ。仮想マシン(VM)、コンテナ、サーバレスアーキテクチャにはそれぞれ特有の長所と短所がある。だがサーバレスは、アプリケーションがその導入アーキテクチャに適さなければ、全てが機能しない恐れもある。IT部門の内部崩壊を防ぐには、開発者に十分な情報を与えた上で、新たな導入についてサーバレスとコンテナの比較を求める必要がある。
コンテナやサーバレスの適合性を判断するには、それぞれの種類のアーキテクチャが実現することや、各アーキテクチャがホストするアプリケーションのユーザーベースと、適切に導入するために必要なことを対比すべきだ。
本稿ではVMを検討の対象外とする。とはいえ、VMはIT部門が最もよく使用し、最も理解しているアプリケーションホスティングアーキテクチャだ。また、インフラを抽象化するアプローチとして最も一般的だが、複雑さとリソースのオーバーヘッドという代償を伴う。本稿では主にサーバレスとコンテナを比較する。サーバレスはリソース全体を抽象化する。これに対して、コンテナはOSの上位に配置される軽量かつ高速の分離層である。
併せて読みたいお薦め記事
コンテナ、サーバレスの特徴
マイクロサービスに取り組むには?
アプリケーションが必要とするもの
サーバレスクラウドコンピューティングには経済的メリットがある。企業は、アプリケーションの実行時のみ、コンピューティングリソースとアプリケーション実行の費用を負担すれば済む。アイドル時間にはコストがかからない。常に準備しておく必要はあるが常時実行されるわけではないアプリケーションやコンポーネントには、サーバレスが最適だ。
例えば、モノのインターネット(IoT)を使った農業用アプリケーションを考えてみよう。このアプリケーションは、湿度センサーを使って土壌の状態を計測する。土壌が乾燥していて水まきが必要だと分かるとイベントを生成する。これまで導入していたアプリケーションでは、雨の日は遊休状態になっていた。アクティブになるまで待機することで不要なリソースが消費される。コンテナシステムでは、アプリケーションが消費するリソースの量を節約できる可能性はある。だが、サーバレスコンピューティングを導入すれば、こうして節約したリソースをアイドル時間に消費することもなくなるだろう。アプリケーションのアイドル時間が長いほど、サーバレスの方が適切に思える。だが、そんなに単純な話だろうか。
いつものことだが、実際は印象よりももっと複雑だ。この例のIoTアプリケーションの場合、サーバレスアーキテクチャには数ミリ秒で利用準備が整うメリットもある。これに対して、コンテナシステムでは数十秒間の準備が必要になる。ただし、起動時間が長いコンテナを導入しても、IoTアプリケーションの目的実現能力に影響する可能性は低い。また、稼働時間よりもアイドル時間が長いアプリケーションなら必ず、コンテナよりもサーバレスの方が向いているというわけではない。サーバレスシステムのロジックは、コンテナシステムよりもコストがかかるだけでなく、技術的にも異なる。
サーバレスとコンテナのテクノロジーの比較
サーバレスについて細かく考えていくとしたら、次のような用語が関係してくるだろう。
- マイクロサービス……アプリケーションを分解した小さなコンポーネント。このコンポーネントは個別に拡張および導入可能
- ステートレス……前に使用したイベントのデータを使用も要求もしないアプリケーション
サーバレスクラウドコンピューティングは、コンテキストに依存しない処理を狙いとしている。つまり、ステートレスアプリケーションを対象とする。イベントに応じてサーバレスアプリケーションがアクティブになると、まず、過去のことを一切記憶していないコードが新たにコピーされる。イベントの中でも、そのイベント発生前のイベントや要求に依存するイベントはステートフルになる。より多くの作業に対処するためにサーバレスアーキテクチャの2つ目のコピーを起動することがある。その場合、2つ目のコピーは、1つ目のコピーが実行していたことを自動的には認識しない。
サーバレス導入でも、クライアント側やバックエンドで状態(ステート)を管理して、ステートフルアプリケーションを機能させることは可能だ。だが、こうした状態管理はアプリケーションのコードに組み込まなければならない。サードパーティー製のソフトウェアにそのようなオプションが存在する可能性は低いだろう。アプリケーションを社内で作成しているとしても、サーバレス導入にステートフルな動作を実装するには、複雑でコストの高い変更が必要になる可能性がある。
コンテナでは、コードに大きな変更を加えることなく、ほぼ全てのアプリケーションやアプリケーションコンポーネントを実行できる。これはサーバレスではできないことだ。大半のビジネスアプリケーションはトランザクション処理を実行し、その過程で1つ以上のデータベースを更新する。こうした処理は、ステートレスな動作にさらに多くの課題を突き付ける。トランザクションを処理するアプリケーションをステートレスにすると、複数のトランザクション間で衝突が起きる可能性がある。それぞれのトランザクションが販売と返品を報告すると、在庫や勘定残高に2つの問い合わせが行われ、それらが衝突した場合、在庫や貸借がゼロを下回る可能性がある。ステートレスな動作とトランザクション処理の動作を組み合わせるようにアプリケーションの設計を見直し、改良することはできる。だが、これは複雑なプロセスで、豊富な経験と多くの作業が必要になる。コンテナならこうしたことは要求されない。
現実と結び付ける
開発者がサーバレスとコンテナを調査する場合、アプリケーションにとって何が最適かを問うことになる。だが、それぞれの導入の懸念事項についても比較検討しなければならない。コンテナネットワークは曖昧さがなく、IPサブネットワークに基づいている。これは最も一般的なアプリケーション導入モデルだ。コンテナシステムはアプリケーション内のプライベートIPアドレス空間を使用する。ただし、管理者が公開するコンポーネントアドレスを選択できる。その結果、仮想プライベートネットワークまたはインターネット上で、ユーザーや他のアプリケーションにサービスを提供することが可能となる。サーバレスコンピューティングの場合、負荷分散やネットワークアドレス指定などの運用面は、サーバレスクラウドフレームワークが処理する。また、アプリケーションコンポーネントを従来型のクラウドやデータセンターでホストしている場合もあるだろう。その際にアプリケーションコンポーネントとサーバレスコンポーネントを統合するには、特別な手順を取らなければならない可能性がある。
コンテナでは長期的にホストする場所が必要になる。一方、サーバレスでは不要だ。コンテナは、アプリケーションやサービスにアクセスする多様なコミュニティーをサポートできる。しかも応答時間が優れている。ただし、地域ごとにコピーを導入することが条件になる。こうした導入モデルでは作業が分割され、さまざまなアプリケーションコピー間でアイドル時間が長くなり、コストが増加する。一方、サーバレスアプリケーションでは、利用可能なリソースがある場所ならどこでもワークロードのコピーを任意の数だけ実行できる。
マイクロサービスをホストする方法
マイクロサービスとは、分散アプリケーションコードの自己完結型コンポーネントで、個別に共有や拡張が可能だ。マイクロサービスはコンテナやサーバレスクラウドでの導入に適している。その差別化要素を突き詰めていくと、使用するマイクロサービスの種類の問題になる。マイクロサービスはステートレスなので、サーバレス導入に向いている。ただしマイクロサービスは、複数のアプリケーションが共有する汎用(はんよう)コンポーネントになることが多い。マイクロサービスが複数の異なるアプリケーションの構成要素になる場合は、コンテナでのホスティングの方がサーバレスよりも適切な導入オプションになる。サーバレスのマイクロサービスを定期的に使用すると、アプリケーションの応答時間が大幅に長くなる可能性がある。これは、サーバレスコンポーネントの導入がオンデマンドで要求されるためだ。
サーバレスは進化していくだろう。だが、サーバレスとコンテナには技術水準とコスト管理の水準の両面に明らかな違いがある。場合によっては、こうした違いにより、どちらか一方を選びがちになる。だが、アプリケーションを計画する担当者によっては混在モデルを採用しなければならないこともある。そうすることで、やや複雑さが増すとしてもだ。必ずしも万能な方法が存在するとは限らない。
Copyright © ITmedia, Inc. All Rights Reserved.
この記事の著者
関連記事
新着ホワイトペーパー PR
-
製品資料
“攻撃者優位”なサイバーセキュリティ、全ての「穴」をふさぐ方法とは? -
製品資料
実際に悪用される脆弱性は4%前後 優先的に対処すべき脆弱性を把握するには? -
製品資料
HubSpotの機能を拡張する法人データ活用法 -
製品資料
面倒で非生産的な「名寄せ」作業 高精度&高効率に実施するには? -
製品資料
名刺管理には「その先」がある 成果のでない営業活動から脱却する秘訣
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
ISMSの“コンサル丸投げ”が招く数千万円の無駄 NTTドコモビジネスの脱出劇
-
2
「VMware離れ」は本当か 3000社がVCF 9にかじを切った現実的な理由
-
3
「Microsoft 365」が乗っ取られる 跡形もなくMFAを破る手口
-
4
なぜ人はいるのにDXが進まない? ライオンも直面した“老害”レガシーシステム
-
5
Netflixのバックエンドは「ほぼJava」 3000超のアプリを支える開発基盤の裏側
-
6
レガシーコードを捨てJavaで勘定系を再定義 ソニー銀行、フルクラウド化の全容
-
7
「0.3秒のスピード顔認証」の入退室管理が社員に好評 事例に学ぶオフィス改革
-
8
マンガで解説:KSK2稼働で何が変わる? 税務調査の高度化に備えるデータ管理
-
9
脱VMwareに待った? AI基盤を掲げるBroadcomの思惑と情シスが直面する新コスト
-
10
221人調査で分かった「情シス最大のストレス」は?
ホワイトペーパーランキング PR
-
1
AIエージェントで多様な日常業務を効率化するための入門ガイド
-
2
AIが「わざわざ使うツール」になっていない? 業務で自然に使う導線にする秘訣
-
3
財務・会計はAI活用でどう変わる? 調査で見えた変革の道筋
-
4
JR西日本ITソリューションズが「監視業務の属人化」を解消した方法とは?
-
5
「脱Excel」か「Excel快適化」か? 現場にやさしい業務改善の進め方
-
6
「結局、一部の人しか使わない」 AI活用が業務に定着しない根本的な理由
-
7
コスト分析で見る「デバイス復旧」の代償 損失額から導きだされた投資戦略とは
-
8
Macの安全神話は崩壊? 最新の脅威動向から見えた攻撃のトレンドと有効な対策
-
9
ゼロトラストにおける「IDaaSの課題」と補完すべき重要機能とは?
-
10
「NAS」「SAN」「DAS」は何が違う? いまさら聞けないストレージの基礎
TechTargetジャパン SNS
インフォメーション
注目情報をチェック
TechTargetジャパンをフォロー