クラウドアプリ開発の初心者向けガイド
クラウドネイティブアプリ開発者なら覚えておきたい「4つの基礎」
クラウドネイティブアプリケーションを開発する際に、検討すべき要素とは何か。基礎となる要素4つと、開発を支援するツールについて説明する。
「クラウドネイティブ」という言葉は、開発者がスケーラビリティといったクラウドの性質を念頭に置いてアプリケーションを設計、開発、提供することを意味する。クラウドネイティブのアプリケーション開発には一般的に、マイクロサービスやコンテナが関連付けられる。これはクラウドネイティブアプリケーションが、最新の開発手法に沿って作成されることが多いためだ。
従来のウオーターフォール型ソフトウェアの開発ライフサイクルとは対照的に、クラウドネイティブアプリケーションはもっとアジャイルな手法で開発されることが多い。自動化されたデリバリーパイプラインを通じて、アプリケーションの運用環境は頻繁に変更され、インフラはコードレベルで管理されるようになった。
併せて読みたいお薦め記事
アプリケーション開発の最新事情
コンテナ型仮想化技術の基礎知識
クラウドネイティブアプリケーションの4つの要素
クラウドネイティブアプリケーションは、インフラの可変性を意識して設計しなければならない。そうしたことから、開発者は「Docker」のようなコンテナ管理ツールに頼ることになる。コンテナ管理ツールは、基盤となるインフラを気にしないでアプリケーションを運用可能だ。
開発者が、複数の独立したマイクロサービスを組み合わせる「マイクロサービスアーキテクチャ」に基づくアプリケーションを構築する際も、コンテナ管理ツールは大いに役立つ。マイクロサービスアーキテクチャは、必要に応じたスケーリングが容易なアプリケーションを実現する。
Herokuの創設者の1人、アダム・ウィギンズが執筆したアプリケーション開発者の参考資料「The Twelve-Factor App」は、クラウドネイティブアプリケーション開発の基礎となる要素を幾つか取り上げている。これらの要素の中から、以下の4つについて詳しく説明する。
- ビルド、リリース、実行
- プロセス
- 並行性
- 廃棄の容易性
ビルド、リリース、実行
「ビルド、リリース、実行」のアプローチでは、クラウドネイティブアプリケーションの開発とデプロイの各段階を区別する。まずアプリケーションのコードを、ソースコードそのものから「ビルド」と呼ばれる実行可能な単位に変換する。次に、このビルドを、実行環境での動作に必要な構成にする。これを「リリース」と呼ぶ。最後に、このリリースしたファイルを実行する。
この明確に定義されたワークフローはしばしば、オープンソースの「Jenkins」や「Capistrano」のような、デプロイと継続的インテグレーション(CI)のためのツールと結び付けられる。これらのツールでは自動テストや過去のビルドへのロールバックを実行できる。問題が発生した場合は、以前に構築したリリースを新しい環境や異なるインフラで再実行できる。アプリケーション全体をデプロイし直す必要はない。
プロセス
クラウドコンピューティングでは、複数のステートレスのプロセスとしてアプリケーションを扱う。ステートレスプロセスは、プロセス同士でデータを共有せず、互いに独立している。そのためプロセス同士でデータを共有し、互いに密接に関連するステートフルのプロセスよりも、はるかにスケーラブルで管理しやすい。
クラウドネイティブのプロセスは、多くの方法で実行できる。Herokuの同名サービスなど、開発者が用意した構成値に基づく独自のランタイム(実行環境)を提供するサービスを使う方法もある。実際のプロセスの実行には、Dockerなどのコンテナ管理ツールを活用するのが一般的だ。コンテナは、特定のアプリケーションの実行に必要な単一のプロセスをカプセル化する。ステートレスのアプリケーションの使用を支援する優れた方法だと考えられる。
並行性
クラウドネイティブアプリケーションは一般的に、サーバの増加で処理能力を向上させるスケールアウトができるようになっている。同時に実行可能な複数のステートレスプロセスに分離できるためだ。プロセスは、それがステートレスの場合、効率的にスケーリングできる。モノリシック(一枚岩)のアプリケーションは、今のところサーバそのもの処理能力を向上させるスケールアップしかできない。
開発者がモノリシックなアプリケーションを複数のプロセスに分割すれば、各プロセスを稼働させるサーバを効率良くスケーリングして負荷に対処できるようになる。こうしたプロセスの管理とスケーリングを自動化するツールは多数提供されている。例えばオープンソースのコンテナオーケストレーションツール「Kubernetes」の他に、クラウドベンダーが提供する専用サービスなどがある。
廃棄容易性
幾つかのクラウドベンダーは、コストを下げるために、ユーザーの入札によって料金が変わるインスタンス(仮想マシン)の「スポットインスタンス」を提供している。スポットインスタンスによって、スケーラビリティをより安価に確保できるようになる。ただしスポットインスタンスにはプロセスが突然終了するリスクも伴う。必ずアプリケーションが強制終了するわけではない。それでも廃棄容易性を目的に設計されるクラウドネイティブアプリケーションでは、アプリケーションの自己修復能力の重要性が高くなる。
アプリケーションの想定外のエラーに備え、シャットダウンの手続きを円滑に進められるようにしなければならない。加えて他のプロセスから分離しないプロセスは、データを保持する、つまりステートフルにする必要がある。自己修復システムは、Kubernetesのようなコンテナオーケストレーションツールや、オープンソースの「beanstalkd」や「RabbitMQ」などの堅牢(けんろう)なメッセージキューイング(MQ:システム同士が任意のタイミングでデータを送受信できる仕組み)ツールを使用して設計する方が簡単だ。
Copyright © ITmedia, Inc. All Rights Reserved.
この記事の著者
関連記事
新着ホワイトペーパー PR
-
事例
[サイボウズ株式会社] DXに必要な「Dスキル」「Xスキル」を持った人材を育成するには? -
市場調査・トレンド
[サイボウズ株式会社] データで見る、DXが「順調に進む企業」と「つまずく企業」の違い -
製品資料
[サイボウズ株式会社] 賛否が割れがちな「Notesからの移行」 新環境への移行を納得してもらうには? -
事例
[ServiceNow Japan合同会社] 農林中金に学ぶ内製開発 処理効率を約2倍に高めAI活用も加速させた方法とは? -
事例
[ServiceNow Japan合同会社] NTTグループのデジタル変革術、17万人が利用する決裁プロセス刷新の全貌
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
AI全部入り「Microsoft 365 E7」に企業が二の足を踏む訳 移行意向はわずか4%
-
2
【基本情報技術者試験】「デュプレックスシステム」と「デュアルシステム」の違いは?
-
3
100億円の「Linux更新」を回避 みずほ銀行が選んだ“おきて破り”のRHEL延命策
-
4
なぜOpenAIやAnthropicのAIは「脱走」したのか 情シスが迫られるエージェント統制
-
5
GitHubが指摘 AIが書いた「おそらく動くコード」が招くシステム崩壊
-
6
「高すぎるGPU」を捨てAI推論をCPUへ Armが示す電力とコストの現実解
-
7
Anthropicが明かす AIは入力データを「どこまで覚えているのか」
-
8
【漫画付き】"RAG導入失敗3例"と処方箋 「入れても使われない」を終わらせる
-
9
「にゃんこ大戦争」がAWSを脱出した理由 無停止移行に潜む“わな”
-
10
なぜ10億円払って“高額な塩漬け”を作るのか? SAPクラウド移行の闇
ホワイトペーパーランキング PR
-
1
生成AIのハルシネーションを防止 回答精度を高めるセマンティックレイヤーとは
-
2
5回聞くだけじゃ足りない? トヨタ式「なぜなぜ分析」の正しい実践方法
-
3
AIエージェントで多様な日常業務を効率化するための入門ガイド
-
4
インシデント対応工数を約3割削減、東京ガスの事例に学ぶ監視体制刷新のコツ
-
5
「脱Excel」か「Excel快適化」か? 現場にやさしい業務改善の進め方
-
6
マンガで解説:「ゼロトラスト」「SASE」の必要性とメリット
-
7
5分で分かる「セキュア大容量ファイル転送サービス」の機能とメリット
-
8
情報セキュリティ対策早分かりガイド:25の自社診断で弱点と解決策を理解
-
9
国税庁の次世代基幹システム「KSK2」稼働開始に向けて、対応すべき変更点とは?
-
10
AIが「わざわざ使うツール」になっていない? 業務で自然に使う導線にする秘訣
TechTargetジャパン SNS
インフォメーション
注目情報をチェック
TechTargetジャパンをフォロー