適したアプリケーションは?
「サーバレスコンピューティング」活用法、パブリッククラウドのコスト削減効果とは
サーバレスコンピューティングはパブリッククラウドでアプリケーションを実行するコストを削減できる。ただしコスト削減をはじめとする各種のメリットを享受するには、適切なスキルセットが必要だ。
「サーバレスコンピューティング」によって、企業はクラウドアプリケーションをより細かい単位で設計し、導入できる。従来のモノリシックなアプリケーションとは異なり、サーバレスアプリケーションはワークロードを複数の関数に分割し、トリガーとなるイベントに呼び出された場合にのみ実行する。
名前に“サーバレス”とあるが、サーバレスコンピューティングはサーバが全く不要なわけではなく、関数をロードして実行するときにのみ使用する。こうしてリソースの使用を最小限に抑えることで、パブリッククラウドの利用料金を抑えようというわけだ。
主要なパブリッククラウド事業者は現在、何かしらの形でサーバレスコンピューティングを提供している。Amazon Web Services(AWS)の「AWS Lambda」、Microsoftの「Microsoft Azure Functions」、Googleの「Google Cloud Functions」などだ。本稿ではサーバレスコンピューティングとは何かを説明し、この最新技術を最大限に活用するための留意点を紹介する。
併せて読みたいお薦めの記事
サーバレスコンピューティングについて
「AWS Lambda」「Azure Functions」を比較
AWS Lambdaに関する記事
サーバレスコンピューティングに必要なスキル
サーバレスコンピューティングは、アプリケーションの設計と管理方法が従来とは根本的に異なる。そのため、この技術を最大限に活用するには、開発者にもクラウド管理者にも軌道修正が必要だ。
開発者にとって最大の違いは、アプリケーションの構造だ。従来型のモノリシックなアプリケーションは多くの場合、変数を介してデータをやりとりするルーチンに依存する。この方法を進化させたのがマイクロサービスだ。マイクロサービスはソフトウェアを小さな機能要素に分割した上で、機能要素を個別にスケーリングし、APIを介してデータをやりとりする。これをさらに極端にしたのがサーバレスコンピューティングだ。サーバレスコンピューティングはソフトウェアの機能を個別の関数に分割し、必要なときにだけ起動する。こうして核となるアプリケーションを小さくすることで、クラウドコンピューティングのインスタンスを小さくし、コストを抑えることが可能だ。
サーバレスコンピューティングの影響はクラウド管理者にも及ぶ。クラウド管理者は例えば、何十もの関数のアベイラビリティとパフォーマンスを監視しなければならない。各関数について、パフォーマンスを監視し、トラブルシューティングを実施し、利用状況とコストを追跡して、そうしたコストをアプリケーション全体のコストとして集計する必要がある。関数の分析と評価には、Azure Functionsの「モニター」タブなど、パブリッククラウド事業者が提供する監視機能を利用できる。
さらにクラウド管理者は、継続的な管理データを開発者と共有するためのメカニズムも構築しなければならない。こうすることで、サーバレスアプリケーションを継続的に改善し、パフォーマンスとコストの最適化を図ることができる。
サーバレスコンピューティングに適したアプリケーションとは
サーバレスコンピューティングが最も適しているのは、多くのリソースを必要とせず、依存関係が最小限で、実行に長時間を要さない、小さくてステートレスな関数だ。関数はできる限り素早く、始動、実行、終了する必要がある。実行に大量のリソースや長い時間を必要とするタスクは、従来型の仮想マシン(VM)やコンテナ導入の方が向いている。
関数は通常、リソースと同時処理数と導入規模に制限がある。クラウド事業者はインスタンスを迅速にスピンアップ(起動処理)し、関数のコードをロードして実行するためのリソースを提供する必要があるからだ。例えば、AWS Lambdaのリソース制限は現在、一時ディスク容量が512MB、ファイル記述子の数が1024個、プロセスとスレッドの数は合わせて1024個、リクエスト当たりの最大実行時間は300秒となっている。
パブリッククラウドのコストを削減
サーバレスコンピューティングの強みの1つは、パブリッククラウドにおいてオンデマンドで仮想マシン(VM)インスタンスを使う場合と比べて、アプリケーションの設計によってはコストを削減できる点だ。コスト削減の規模はアプリケーションの性質によって異なる他、アプリケーションがどの程度イベント駆動型の関数として設計、導入されているかや、関数を呼び出す頻度によっても異なる。イベントが発生したとき以外、アプリケーションの大半がアイドル状態にあるようなら、コストの削減を見込める。
ただしパブリッククラウドにおいてオンデマンドでVMインスタンスを使用する場合と比べて、コストを常に削減できるわけではない。無料層を除けば、関数の呼び出しは常に料金が発生する。関数ベースのアプリケーションのコストはおおよそ各関数のコストの合計となる。各関数のコストは基本的には、呼び出し回数に呼び出し1回当たりのコストを掛けた数字だ。
例えば50~100個程度の関数で構成されるサーバレスアプリケーションを、数万あるいは数十万という規模のモバイルユーザーベースが利用するとする。このような場合、クラウドの利用料金が請求されるころには、関数の呼び出し回数が膨大な数にふくれ上がっている可能性もある。そうなれば、従来型のアーキテクチャで設計した場合よりもコストがかさむ。ここでの問題は、一部には利用予測が不明確なことにある。大半の開発者は、関数がどのくらいの頻度で呼び出されることになるかを把握していない。そのためコスト分析が難しくなる。
サーバレスアプリケーションのコストを予測するには、関数の使用規模とユーザーベースの規模を慎重に評価する必要がある。アプリケーションの設計の違いが運転コストにどのような影響を及ぼすかについての検討も重要だ。アプリケーションの設計に変更を加え、一部の関数の多用を回避することで、コストを減らせる場合もある。
導入前の留意点
サーバレスコンピューティングは説得力のある概念だが、考慮すべき重要な点が幾つかある。導入前に慎重に検討すべき項目を以下に示す。
パフォーマンス
関数のレイテンシとパフォーマンスが及ぼす影響を考慮する。関数は実行時にその都度ロードするので、レスポンスタイムには小さいながらも確実にレイテンシが生じる。レイテンシはトラフィックの需要によっても変わる。レイテンシに敏感なアプリケーションの場合、こうした点がサーバレスコンピューティングの魅力を損なう可能性がある。
複雑さ
関数はアプリケーションの設計やパフォーマンスの監視、トラブルシューティングを複雑にする可能性がある。クラウド管理者は何十あるいは何百種類もの関数を監視しなければならないからだ。現在よりも細かい管理が可能なツールとポリシーの使用を検討するといい。
ステートレスな設計
関数はその都度素早く実行する必要があるので、ステートレスなソフトウェア設計が向いている。関数間でステートをやりとりするなら、関数ではなくデータにステートを割り当てること。ただし関数間で受け渡すメッセージのサイズには通常、厳しい制限がある。
エラー対策
関数は多くの場合、他の関数やストレージ、バックエンドアプリケーション、ネットワークアベイラビリティなどに依存するが、これらの要素はいずれもエラー発生の可能性がある。関数はエラーに対処できる設計にすべきだ。エラー後の実行時に未完のタスクを完了することで、できるだけエラーに強い関数を目指す。
移植性
関数は通常、パブリッククラウド事業者間で移行することはできない。AWS Lambdaの関数はAzureやGoogleでは動かず、その逆も同様だ。この状況はベンダーのロックインを引き起こし、マルチクラウド戦略を複雑なものにする可能性がある。
Copyright © ITmedia, Inc. All Rights Reserved.
この記事の著者
関連記事
新着ホワイトペーパー PR
-
製品資料
[株式会社MatrixFlow] 「物流リソース最適化」ガイド:人員・配車・傭車を出庫依頼の確定前に決めきる -
製品資料
[株式会社キーエンス] なぜRPA導入は頓挫する? シナリオ作成の壁を乗り越える解決策とは -
製品資料
[株式会社セールスフォース・ジャパン] 「CRMは設計と無関係」は本当か? PLMとの融合で実現する高速開発 -
事例
[日本ヒューレット・パッカード合同会社] AIエージェントの時代にどう備える? 「新たな働き手」を支える3要素とは -
製品資料
[日本ヒューレット・パッカード合同会社] “横並びの自動化”から脱却、AI活用で生産性と競争力を高める秘訣
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
法務と開発者で「言葉が通じない」問題 トヨタやソニーが語るOSS管理の真実
-
2
なぜ「全社配布Copilot」は使われないのか? 失敗に学ぶAI定着
-
3
なぜ「Gemini 4 Argon」は出遅れたのか? Googleが狙う“逆転のシナリオ”
-
4
ChatGPTは“検索しまくり”でGeminiは“淡泊”? データが明かすAIの裏側
-
5
損保ジャパンはなぜ「COBOL」を捨てなかったのか? 脱メインフレームの真相
-
6
【漫画付き】ひとり情シス協会が明かす、RAG導入でしくじる企業「2つの共通点」
-
7
AI時代のITインフラ戦略とは? 販売代理店が知っておきたい最新トレンド
-
8
情シスの約8割が転職や退職を意識 調査で分かった“辞めたくなる最大の理由”
-
9
人間のせいでAIエージェントの生産性が上がらない
-
10
「IBM i(AS/400)はクローズドなシステム」という誤解 DXに寄与する一歩
ホワイトペーパーランキング PR
-
1
不審メールの経路や見せ方に変化? 2026年夏の3事例から見えた動向と対処方法
-
2
家庭用Wi-Fiルーターの業務利用は危険? 避けるべき理由と具体的な対策
-
3
Microsoft 365を安全に運用 うっかりミスやサイバー攻撃に備えるデータ保護術
-
4
財務部門がAIを最大限に活用する方法 無駄のない戦略的リーダーシップへの道
-
5
LLMが兵器化? 元FBI高官が鳴らす警鐘とセキュリティツール統合のポイント
-
6
「オンプレミス回帰」せざるを得ない“合理的な理由”
-
7
なぜRPA導入は頓挫する? シナリオ作成の壁を乗り越える解決策とは
-
8
生成AIを開発に導入しても効果が見えない? 実証実験で分かった成果と課題
-
9
経産省DX指針から読み解く、受発注業務デジタル化ロードマップ
-
10
HDDを使わない「SSDオンリー」が無謀なのはなぜ?
TechTargetジャパン SNS
インフォメーション
注目情報をチェック
TechTargetジャパンをフォロー