パブリッククラウドの活用が進むが、同時に隔たりも進んでいる
中井氏は従来型のサービスを「Mode1」とクラウドネイティブ「Mode2」と分類し、「求められるものが異なる」と解説する。つまり、従来型サービスではビジネス手順の管理やガバナンスが目的であり、安定性・堅牢性が不可欠。一方で、クラウドネイティブサービスでは、アイディアとITを組み合わせて“収益を上げること”が目的であり、迅速にサービスインできることや多量のデータやアクセスにも耐えうる拡張性、変化に合わせて頻繁に機能を更新できる環境などが求められる。
日本ヒューレット・パッカード株式会社 ハイブリッドIT事業統括
クラウドソリューション本部 本部長 中井 大士氏
こうした異なる要件を持つシステム環境のそれぞれにどのように対峙し、両立させていくか、悩んでいる人も多いだろう。そこで重要となるのが「ハイブリッド／マルチクラウド」という考え方だ。各システム要件に合わせてクラウドやオンプレミスなど最適なものを選び、並行して活用していく。つまり“適材適所（Right Mix）”による運用が有効となるという。
［画像クリックで拡大表示］
実際、ユーザー企業への意識調査では、2020年にはエッジで生成されるデータは全データの70%に上ると考えられており、68%のユーザー企業が2年以内にマルチクラウド環境の運用になると回答しているという。また2017年にパブリッククラウドからアプリケーションをプライベートクラウドやオンプレミス環境に戻したユーザー企業は34%に上り、2015年が21%であったことを鑑みると、今後はさらなる試行錯誤や乗り換えが頻繁となり、インフラ環境の管理が煩雑かつ困難になることが予測されているという。
中井氏はそうした傾向を踏まえ、「パブリッククラウドの活用が進むが、同時に隔たりも進む」と分析する。つまり、それぞれ求める要件からオンプレミスとパブリッククラウドを選ぶものの、運用性やスピード感、投資モデルも異なるために容易に行き来は難しく、運用管理も煩雑化するという。その結果、Mode1をオンプレミスで、Mode2だけをパブリッククラウドでと切り分ける会社も少なくない。
Mode1についてのユーザー企業への調査では。オンプレミス環境でのサービス開始の遅さ、容量やリソースの拡張しにくさ、運用コストやリスク対策費の高額化といった不満が浮き彫りになる。特に最も深刻化しているのが人の問題だ。運用できる技術者が不足し、いてもスキルが属人化してしまう。デジタルトランスフォーメーションを加速したいという思いがあっても、既存の環境で手いっぱいで人もコストもまわせないというのが実情のようである。
一方、Mode2では、“乗せ替え”が問題となっている。サービスのスモールスタートにパブリッククラウドを使用したものの、ユーザーやデータが増え、サービスの利用が拡大するうち、今後の展開を考えるようになる。というのも、パブリッククラウドが本格的に使うと意外と安くないことが分かり、年間約50分の停止というSLAレベル（99.99%）、そしてストレージやネットワークの性能担保といった面が検討課題となって別の選択肢が出始める。事実、ヒューレット・パッカードでは、オンラインストレージサービスを展開する「Dropbox」のパブリッククラウドからハイブリッドクラウドへの移行を支援した事例もあると説明する。
オンプレミス基盤の改革の必要性と「インフラのコード化」
新たなデジタライゼーションの実現に向け、人材不足対策とパブリッククラウドからの受け皿・連携が大きな課題であることは明らかだ。この2つの要因から、中井氏は「オンプレミス基盤の改革の必要性」を訴える。
人材不足への対策としては、既存基盤運用の省力化・自動化を進め、属人性を排除すること。そして、パブリッククラウドで担保できない部分を補足し、受け皿や連携先となるために、クラウドのような俊敏性を実現し、クラウドのような運用方式を持ち込むことが必要だという。
そこで鍵になるのが「インフラのコード化」だ。既存のシステムを含めて管理の自動化・省力化、俊敏性の向上を行なうことで、人材を運用管理から新サービスの企画検討へと移し、デジタライゼーションを加速させる。そして、ハイブリッドまたはマルチクラウドの適材適所の環境を運用するために、オンプレミスとの併用もさることながら、異なるクラウドの運用方式の共通化やクラウドサイロの排除、属人性の排除を実現させていこうというわけだ。
ここで中井氏は「DevとOpsのサイクル速度の違い」に触れる。近年のアプリケーション開発のサイクルはどんどん迅速化していると言われるが、実際は「Dev＝開発」の方のサイクルはツールなどによる自動化が進んで速くなっていても、「Ops=運用」がそれに追いついていないケースが少なくない。そこでDevの取り組みをOpsに適用しようというのが、「インフラのコード化」の考え方だ。
講演資料より［画像クリックで拡大表示］
手作業だったインフラの構築や運用を全てコード化する。つまり、コードをアプリケーションのために書くのではなく、インフラの管理のために書くという考え方であり、今後は内製化においてエンジニアのキースキルになるという。
例えば、下図のようにアプリケーション開発において「App v1」を作成し、アプリケーション実行環境にデプロイしたとする。アプリケーションに変更があって「App v1.2」となれば、実行環境もライブラリかパラメータを変えなければならない。この時、従来においては手動で行われていた変更を、アプリケーションと同様、「Infra v1」「Infra v1.2」というようにコードで制御し展開できるようになる。
［画像クリックで拡大表示］
もちろんアプリに関係なく「Infra v1.2」をデプロイしたいとなれば、作業することなく他の環境にも展開できる。逆にオペレーション側の都合で、あるパラメータを変えなければならない場合も、例えば多数のVMの構成情報を取ってきたり、全部の環境を少しずつ変えたりすることも、コード化して適用すれば容易に制御できるという。こうした方法は「コンフィグレーションコード」とも呼ばれている。
なおアプリケーションとその実行環境をパッケージしたのが「コンテナ」だ。アプリケーション側でコンテナごと開発してしまえば、実行環境もコードで制御・展開ができる。そうなれば、DevとOPsの境界線が若干変わってくることにもなるという。
コード化によって、APIやスクリプトで対象をコントールできるようになれば、アプリケーションのインストールやOS上の設定などの実行、OSインストールやVMのデプロイなども可能になる。また、例えばAnsibleなら各種のレイヤで幅広いツールとの連携が可能になっており、Ansibleを使って知らぬうちに「インフラのコード化」を進めている人も実は多く存在しているという。
このように、インフラのコード化が進めば、これまで手作業だったオペレーションの工数や時間が削減され、品質も均一に担保される。また、自動化やバージョン管理が容易になり、システム運用の標準化を進めることにもなるだろう。また、作業に人の手が入らない自動化によって、内部統制やセキュリティ対策面での効果もできる。中井氏は「迅速性・コスト削減・リスク排除というあらゆる面でメリットが大きい」と強調した。
成功のポイントは「できるところからやること」
こうした「インフラのコード化」による先進的な取り組みは欧米で数多く進んでおり、「Everything as Code」としてエンタープライズのITに根付かせようという意識が高いという。
例えば、ヒューレット・パッカード エンタープライズ（以下、HPE）自身もまた、様々なアプリケーションを多く開発する中で「Everything as Code」を掲げ、アプリケーションはもちろん、コンフィグレーション、環境、データ、インフラと、変更が発生するものは全てコード化を進めている。そして、継続的なデリバリのパイプラインに乗せ、組織統一の変更・導入管理を実施することに成功した。導入のポイントは、全てを一気にコード化・自動化しようとせずに、「できるところからやること」だという。
かつてはHPEでも一部の部門による断片的な取り組みで、ツールもサイロ化され、プロセスやテンプレートに基づくリソースデプロイだった。それがコード化が組織横断的に活用されるようになり、統一された継続的デリバリ環境を実現し、APIによる動的なリソースデプロイが可能になった。ハードまで含めたコード化によって、あらゆるプロセスの自動化が進み、400の変更を2週間でできるようになり、それもダウンタイムなしで実現できるようになったという。
中井氏は「インフラのコード化において『Everything as Code』を掲げて『迅速性』『コスト削減』『リスク排除』を追求することで、組織への定着を図り、効果の最大化を測ることができる」と語る。ハードも含めてコード化すれば迅速性が高まり、組織横断的な活用促進がかなえばコスト削減にもつながる。さらに統一された継続的デリバリ環境が実現すれば、リスク排除にもなる。当然、適用の範囲が拡大すれば、効果の範囲も広がる。これを「小さく始めて大きく育てる」というわけだ。
実は日本においても、Ansibleを一人の担当が使い、それが部門長に上がって部門内で使われるようになるといった話は少なくないという。その際、例えば権限を持ってコントロールする、フローを束ねて管理するなど、組織として活用するにはAnsible Towerなどの有料ツールを利用するのがよい。標準化やガバナンス管理の徹底が可能になり、リスクを最小限に抑えられる。
そこで、マルチテナントでリソースを柔軟に切り替えるワークフローを構築し、また時間や分量などで分割して、標準化と再利用を図ることでリソースの効率向上やコスト削減につなげる。フローで権限を変えるなども、組織横断的に行う場合には必要になってくるという。
アプリケーションの開発フローとして、アプリケーションエンジニアとインフラエンジニアの工程を並行して走らせることは多いが、その際にインフラ側のパイプラインにもしっかりとデプロイテストなど自動テストツールなどをのせる。またChatOpsのようなものでコミュニケーションしながら、システムと連携させて状況管理する方法なども用意されている。
HPEの事例のところでも少し触れたが、コード化の範囲をハードウェアまで行う考え方も進化しつつある。これまではOSやアプリなどが中心だったが、ハードウェアインフラの抽象化を実現した製品が登場している。その製品「HPE Synergy」は、単一APIでコントロールができ、数分程度の迅速なインスタンス立ち上げや月額従量課金にも対応するなど、パブリッククラウドの運用性をハードの中に閉じ込めたイメージだ。
こうしたことは従来のサーバなどでもできなくはなかったが、それぞれで仕様が異なるAPIに対応し、それに合わせる必要があった。しかし「HPE Synergy」は、単一のAPIでサーバもネットワークもリソースも、全て管理ができるのが強みだ。
［画像クリックで拡大表示］
この「HPE Synergy」を活用した例として株式会社ジェーシービーの事例が簡単に紹介された。同社では、クラウドネイティブアプリケーションに特化したセキュアな開発環境を「HPE Synergy」上に構築。その結果、アジャイル開発体制を確立し、開発のスピード化と多様な開発要求に応える柔軟性を両立させ、同社のデジタルイノベーションを加速させているという。
最後に中井氏は「デジタライゼーションにフォーカスし、サイロのないマルチクラウド環境を実現するためには、 既存のオンプレミス／プライベート基盤の改革は必要不可欠。そして、インフラのコード化の考え方が有効となる。ツールは様々な選択肢があるので、是非とも相談の上、可能なところから進めてほしい」と改めて語り、セッションを終えた。
【解説資料】これぞ究極のDevOps！「インフラのコード化」（Infrastructure as Code）とは何だ？
資料『DevOpsとInfrastructure as Codeが変えるこれからの企業のITインフラ』（全8頁、無料PDF）は、迅速性、リスク低減、コスト削減を実現する「インフラのコード化」という考え方やビジネス効果、そして具体的な手法を解説した資料です。ぜひ、本資料をご一読いただき、 DevOpsの推進やIT運用の改善にお役立てください。
