必要なのは既存の枠にとらわれない発想
クラウドの運用管理を自動化する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
-
市場調査・トレンド
[AvePoint Japan株式会社] SCS評価制度の死角は“SaaSの中” クラウド標準機能では届かない領域とは? -
製品資料
[デジタルサーカス株式会社] 5分で分かる、「オープンソースCMS」比較ガイド -
製品資料
[デジタルサーカス株式会社] 1つのアプリを各国で運用 多言語モバイルアプリを簡単に開発・導入できる方法 -
製品資料
[ニュータニックス・ジャパン合同会社] 複雑化するKubernetes運用、VMとコンテナの二重管理を解消する方法は? -
市場調査・トレンド
[アルプス システム インテグレーション株式会社] 急増する高度なフィッシング詐欺 先回りしてブロックするには何が必要?
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
PHPはそもそも必要か? 脆弱性で問われる自社サイト安全性と保守負担のバランス
-
2
Microsoft 365導入後も稟議は「Excelをメールで回覧」 承認が止まる理由
-
3
米国防総省で300万人分の個人情報が流出 その「意外な原因」と教訓
-
4
PHP脆弱性「PHP2Shell」で2260万件に影響 情シスの緊急チェックリスト
-
5
「Microsoft 365」が乗っ取られる MFAを破る“本物の画面”の恐怖
-
6
京王電鉄・東京メトロの被害から学ぶ境界防衛 ITの侵害はどこまで波及するか
-
7
金融・通信で情報漏えいが続出 IPAとJPCERT/CCが情シスに求める緊急点検
-
8
半数がブルーカラー転向を視野に? ベテランエンジニアを追い込む“54歳の壁”
-
9
「レガシーシステム・老朽化システムの運用課題と刷新」に関するアンケート
-
10
「Wi-Fi 7」経由でWindowsが乗っ取られる? 最高権限奪取の恐怖
ホワイトペーパーランキング PR
-
1
AI駆動攻撃にどう対抗する? 超速の攻撃からエンドポイントを保護する方法
-
2
最速72分でデータが流出? 最新の脅威トレンドや侵入手法から分かった防衛策
-
3
経験豊富な即戦力人材に直接アプローチできる、「攻めの採用」への転換術
-
4
2026年のサイバーセキュリティには何が必要か? 最新データに学ぶ傾向と対策
-
5
「IT史に名を残すシステム障害」8選
-
6
「EDR」選定ガイド:比較・検討フェーズで整理すべきポイントを解説
-
7
10G回線の真価をフルに享受するには? 導入前にチェックしたいポイント
-
8
HDDを使わない「SSDオンリー」が無謀なのはなぜ?
-
9
MDMだけでは防げない? Appleデバイスに潜む5つのセキュリティギャップ
-
10
なぜRPA導入は頓挫する? シナリオ作成の壁を乗り越える解決策とは
TechTargetジャパン SNS
インフォメーション
注目情報をチェック
TechTargetジャパンをフォロー