必要なのは既存の枠にとらわれない発想
クラウドの運用管理を自動化する2種類のDevOpsツール
本格的なクラウド自動化ツールの多くは、DevOps(開発運用連係)製品のカテゴリーに含まれる。DevOpsツールにはモデル型とスクリプト型の2種類がある。それぞれの仕組みを解説する。
ITの歴史を振り返れば、アプリケーションの開発は「ボックス型」モデルで行われるのが一般的だった。このモデルは、各コンポーネントがマシンのイメージにリンクされ、そのイメージをデータセンター内の静的サーバ上でホスティングするという方式だ。リソースの柔軟性とアジリティ(即応性)を目標とするクラウドでは、アプリケーションのコンポーネントとそのリソースの間で動的な関連付けが求められる。それを実現するのがクラウドの自動化である。ただし、そのためには適切な計画と実装が必要だ。
自動化とは、アプリケーションのコンポーネントの配備と再配備をソフトウェアで制御することによって、コンポーネント間およびアプリケーション間のリンクを正しく確立・維持するプロセスを指す。具体的には、自動化には2つの基本的要素が必要となる。
- アプリケーションコンポーネントの配備(ソフトウェアコンポーネントやデータベースコンポーネントなど)
- ネットワーク接続の作成(コンポーネント間の通信ならびにユーザーおよび他のアプリケーションとの接続を可能にする)
この定義は、さまざまな自動化用技術やツールの全てに当てはまるが、その手法には大きな違いがある。
ハイブリッド型クラウドアプリケーションでは連係によりシンプルな自動化を実現
最もシンプルなタイプの自動化は連係である。これは、クラウドに配備されたコンポーネントと、固定されたアプリケーションやリソースを接続するという手法だ。ハイブリッド型クラウドアプリケーションでは、クラウドコンポーネントとデータセンターを連係するだけで自動化を実現できる場合もある。
クラウド連係用の商用ツールは、大手ソフトウェアベンダーおよびサードパーティーから何種類か出回っている。その多くは、ハイブリッド型クラウド構成において特定のアプリケーションを連係するための既製“レシピ”を提供する。この種の製品を採用するに当たっては、自社のアプリケーションニーズに対応できるかどうかをベンダーに確認する必要がある。
DevOps型自動化ツールはスクリプトベースのアプローチを採用
より本格的なクラウド自動化ツールの多くは、DevOps(開発運用連係)タイプの製品カテゴリーに含まれる。DevOpsの前提となるのは、アプリケーションがどのように配備され、コンポーネントがどのように接続されるかをアプリケーション開発者が知っていることだ。開発者は開発プロセスにおいて、この配備/接続関係を示した「DevOpsマップ」を作成する。このマップはアプリケーション配備の際に必要に応じて利用される。
DevOpsツールにはモデル型とスクリプト型が存在する。最もシンプルなDevOpsプログラム(あるいはスクリプト)としては、一連のコマンドという形態が考えられる。運用チームの担当者がこれらのコマンドを入力して、アプリケーションの配備・接続を行う。配備段階で設定されるIPアドレスなどの情報にはシンボリック名が与えられる。コンポーネントが配備された時点で必要な情報に置き換えられ、参照が可能になり、コンポーネント間の接続が作られる。
スクリプト型のツールのメリットは、手作業のプロセスを容易に置き換えられることだ。一方、最大のデメリットは、結果ではなくプロセスを記述するという点にある。すなわち、遭遇する可能性のある全ての状況に対する命令をスクリプトとして記述しなければならないのだ。「DevOpsのスクリプトはソフトウェアよりもメンテナンスが難しいこともある」と指摘するユーザーもいる。スクリプトを読んだだけでは、どんな結果が期待されているのかが分かりにくいからだ。スクリプトベースの自動化を使用するのであれば、処理の内容を正確に示した説明を記述するとともに、スクリプトが対処できない状況を示すことが不可欠だ。
DevOpsツールにはオープンソース製品と商用製品があるので、自社の環境と開発チームに最も適した製品を探す必要がある。
クラウドプロバイダーとの相性が良いモデル型アプローチ
スクリプト型自動化は仮想化では標準的な方式であるが、ネットワーク事業者やクラウドプロバイダーはモデル型アプローチを好む。サービスのライフサイクル管理が容易だというのが理由だ。モデル型自動化では、開発対象の構造と制約条件(コンポーネントの動作条件や接続の種類など)を記述するだけで、後は定義された構造がソフトウェアによって作成される。一般的に、これらのモデルは読みやすく理解しやすい。DevOpsのように、ある状態に達するための手順を記述しているのではなく、何を実現しようとしているのかを記述しているからだ。これらのモデルを使えば、「問題が発生したアプリケーション要素を修正する」「アプリケーションを分解する」「ライフサイクルを変更する」といったことが可能になる。スクリプト型自動化でこうした処理を行うには、個別のスクリプトを作成する必要がある。
しかしクラウド環境では、スクリプト方式とモデル方式を組み合わせたハイブリッド型アプローチが増えている。その背景には、ユーザーのニーズと事業者のニーズが異なることがある。例えば、OpenStackでは、モデル型アプローチをアプリケーションに適用すれば、コンポーネントをホスティングする一連のサブネットを作成し、これらのコンポーネントがより高レベルのネットワークに接続される。OpenStackのネットワーク部分である「OpenStack Neutron」はネットワークモデルを定義するが、アプリケーションとデータベースのコンポーネントを配備するには、他のOpenStackサービスを利用する必要がある。OpenStackを利用したDevOpsツールは、Neutronネットワークモデルを作成した上で、定義されたネットワーク要素にコンポーネントを(コンピューティングリソースまたはDBMS/ブロックストレージを使って)配備するという形になると思われる。
クラウド自動化への段階的アプローチ
あなたの会社がどのツールを選択するにせよ、クラウド自動化に向けた最初のステップは、全て手作業でアプリケーションを配備し、各手順を丁寧に記録することだ。特に、ある手順の結果が後で使用される箇所(例えばコンポーネントのアドレス)は全て記録する必要がある。これによって、自動化を完成させるためのベースラインが確立し、手作業の手順の記録をスクリプトあるいはモデルの作成に利用できる。
スクリプト型自動化プロセスは、これらの手作業の手順に基づいて構築され、過去の手順の結果への参照は全て変数で置き換えられる。こうすることで自動化のスクリプトが汎用的なものになる。複雑そうに思えるかもしれないが、Webページを制御するためのJavaScriptを記述するのとさほど変わらない。
モデル型自動化では、その目標(例えば定義済みのサブネット上でコンポーネントをホスティングする)に応じて手順をグループ化する作業が必要とされる。これらのグループは利用可能なモデルに対応していなければならない。
クラウド自動化の最後のステップはテストだ。自動化のスクリプトまたはモデルが起動すると、所定の機能を実行するソフトウェアシステムが配備されなければならない。手作業のプロセスと異なる動きがあれば、見直しを行い、自動化のエラーが生じないようにすること。テスト/検証作業の手順を記録することも忘れてはならない。クラウド自動化は、アプリケーションライフサイクル管理と、ビジネスを支えるアプリケーションの安定稼働にとって不可欠な要素であるからだ。監査可能なソフトウェアライフサイクルプロセスを導入してクラウド自動化を正しく実現・運用しなければ、後悔することになるだろう。
Copyright © ITmedia, Inc. All Rights Reserved.
この記事の著者
関連記事
新着ホワイトペーパー PR
-
製品資料
[株式会社MatrixFlow] 「物流リソース最適化」ガイド:人員・配車・傭車を出庫依頼の確定前に決めきる -
製品資料
[株式会社キーエンス] なぜRPA導入は頓挫する? シナリオ作成の壁を乗り越える解決策とは -
製品資料
[株式会社セールスフォース・ジャパン] 「CRMは設計と無関係」は本当か? PLMとの融合で実現する高速開発 -
事例
[日本ヒューレット・パッカード合同会社] AIエージェントの時代にどう備える? 「新たな働き手」を支える3要素とは -
製品資料
[日本ヒューレット・パッカード合同会社] “横並びの自動化”から脱却、AI活用で生産性と競争力を高める秘訣
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
なぜ「全社配布Copilot」は使われないのか? 失敗に学ぶAI定着
-
2
法務と開発者で「言葉が通じない」問題 トヨタやソニーが語るOSS管理の真実
-
3
なぜ「Gemini 4 Argon」は出遅れたのか? Googleが狙う“逆転のシナリオ”
-
4
損保ジャパンはなぜ「COBOL」を捨てなかったのか? 脱メインフレームの真相
-
5
情シスの約8割が転職や退職を意識 調査で分かった“辞めたくなる最大の理由”
-
6
ChatGPTは“検索しまくり”でGeminiは“淡泊”? データが明かすAIの裏側
-
7
情報漏えいはなぜ繰り返されるのか 今すぐ見直すべき「境界」
-
8
「Wi-Fi 7」経由でWindowsが乗っ取られる? 最高権限奪取の恐怖
-
9
「結局使わなくなる」Microsoft 365 Copilotを半年で定着 キリンの3施策
-
10
「中堅・中小企業のネットワーク・セキュリティ運用実態」に関するアンケート
ホワイトペーパーランキング 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ジャパンをフォロー