背景
クラウド時代と言われて久しく、「クラウド」という単語が一般消費者にも認識されるほど広くコモディティ化が進み、いまでは社会公共基盤や金融といったクリティカルなシステムの基盤として利用もみられてきています。従来のオンプレミス環境とクラウドとの組み合わせであるハイブリッドクラウド、複数の異なるクラウドを複合的に利用するマルチクラウドといった状況も増えてきており、この動きは加速していくものと推測されます。
一方で、クラウドを利用しているのに思ったようにコストダウンを図れていない、クラウドを利用すると運用現場の対応が複雑化するという声も耳にするようになってきました。運用に対する課題認識が十分になされず対処も取られず、結果として現場での対処や後始末に追われてしまい、本来のコストや柔軟性といったクラウドのメリットを生かせない、運用オペレーションも含めたクラウド利用となっていないといった実態となってしまっているということです。
今回は、運用のご提案をする中でお客様からうかがった事例も交えながら、クラウド利用の際に考慮すべきポイントをご紹介いたします。
クラウド利用における運用上の課題
１．クラウドのリソース変更・拡張の柔軟性を生かすことができない
クラウドのメリットのひとつに、リソース制御の柔軟性があげられます。従来のオンプレミスのようにピークに合わせた設計ではなく、「必要な時に必要なだけ」とすることでコストの最小化を図ることができます。例えば年末商戦にむけてキャンペーンをうつ、期末で財務情報の集計処理を行うといった、多くのトラフィックやCPUパワー、ストレージを必要とするタイミングのみリソースを拡張し、平常時はできる限り縮小する、場合によっては停止するという形です。クラウドの多くはリソースの利用に対する従量課金であることが一般的で、この仕組みを積極的に活用することで大きなコストダウンを図れます。
つまり、いかに「使う時だけ」を見定め、「業務の運行スケジュール」と綿密に連携した「クラウドのリソースコントロール」を行えるかが重要となります。こういったコントロールは、対象の業務・システムの規模感が大きくなれば必然的に複雑度・難易度もあがるため簡単な話ではないことも事実ですが、現行システムからの大幅な変更を伴わない範囲でのクラウド利用にとどまっている実情が背景としてあるようです。
また、オンプレ環境からのクラウド移行を考える際、従来利用していたミドルウェアをそのままクラウドに持ちこむことにも課題があります。クラウド柔軟性とコストに着目すると、従来のミドルウェアのライセンス/費用の体系が「数えるモデル」であることを原因とした影響があります。利用するユーザ数であったり、インストールするサーバ数を数えることに加え、自身の機能が及ぶ他のサーバ数(エージェント数)、さらにそれぞれのCPUコア数やネットワークポート数などを数え、年間費用として積み上げてライセンス費用となるのが一般的です。このライセンスモデルをそのままクラウドに持ち込むと、ライセンスコストは契約期間のなかで最大値で見積もるというのが正しいやり方となるようです。
このこと自体がライセンスコスト高の原因でもありますが、ライセンス違反にもなりかねないため最大値で見積もるようなミドルウェアが複数あることは柔軟なリソースコントロールの必要性の希薄化につながることになります。特に全サーバに機能が及ぶようなシステム運用ソフトウェアやセキュリティ製品などではこういった課題が顕在化しやすいと言えます。
２．クラウドだから監視しないで良いという誤解、従来と監視にやり方が異なることへの認識不足
大げさに聞こえるかもしれませんが、クラウドだから監視しないで良いという誤解をお持ちの方はいるようで、現場の方はご理解があってもその上司の方への説明に苦慮されるケースをお伺いします。IaaS、PaaS、SaaS、マネージドサービスなど、様々なクラウドサービスが一緒くたにクラウドと語られている中で生じる誤解かもしれませんが、クラウドサービスの中でもクラウド事業者が担保してくれる範囲もあるため、一概に間違いというわけではないとも言えます。ただ、システム・サービスとして追加で監視が不要かというと決してそうではないので監視するポイントの把握と監視する仕組みの理解をもって設計することが必要です。
著名なパブリッククラウドであれば専用の監視システムを持っているので、それを活用することでIaaS、PaaSまでであれば監視が可能です。ただし、システムとして成り立たせるには、これらIaaSやPaaS上にミドルウェアや業務アプリケーションを稼働させることになりますが、パブリッククラウドが提供する専用の監視システムではこれらのユーザ持ち込みのミドルウェアはアプリケーションには対応していない、もしくは、機能としては存在するものの個別設計が必要となることが一般的で、結果として、従来と同レベルの監視を実現するには別途監視の仕組みの導入も含めた検討が必要となります。
また、クラウド自体が止まることもあるということも忘れてはなりません。著名なパブリッククラウドでもさまざまな障害が実際に起こっています。近年ではニュースで報道されるような障害事象もあり、読者の皆様にも耳にされた方もいらっしゃるかもしれません(それだけ注目度の高い、多くのサービスの基盤でクラウドが利用されているという事実の裏返しでもあります)。
クラウド自体が止まると書きましたが、実際は特定のサービス、地域といった範囲で何らかの障害が発生し利用が困難な状況になるわけですが、運用としては、障害を検知した際は発生箇所の特定と原因の解析、そして解決策もしくは代替策を講じるとともに、利用者へのアナウンスを円滑に行うことで、障害自体および派生から発生する影響を極小化しなければならないところです。影響の度合いは別として、結果としてはシンプルな事象であるのですが、従来のシステム監視の延長で行っていると最初に発生した特定の箇所でつまずいてしまい対応に時間を要してしまうことになります。
実際、当社のお客さまでもシステムの中ばかり見ていて自力での特定に至れず、同じクラウドサービス利用者のインターネット上でのつぶやきが役に立ったという話もお伺いしたことがあります。最終的な利用者とのSLAやSLO、利便性の追求のためには可能な限り迅速に、確実性の高い手段を事前に講じておく必要があります。
３．自動化の核となる運用ツールの可用性担保のしづらさ
システム運用の重要な要素に業務処理の自動化が挙げられます。簡単にいうと指定の日時になったら決められた処理を自動実行するものですが、バッチ処理、ジョブスケジューラ、ジョブ管理、ジョブネットといったキーワードで認識されている方もいらっしゃるかと思います。いまやシステムの運行には欠かせない要件といっても過言では無いですが、これを満たすための運用ツールの選択肢はそれほど多くありません。正確には、近年、自動化をうたうツールは多くありますが、従来システムで行っているような自動化の受け皿となりえるツールは限られるということです。
例えば、月末月初、営業日指定、祝日振替、繰り返し実行といった実行タイミングや、実行するもののなかでも処理や実行サーバの分岐と待ち受け、実行失敗時の再実行、他システム待ち受けなどきめ細かな制御が行われています。この綿密に組まれた自動化は日本特有とも言われており、一般的には国外製ツールでの対応が非常に難しいのが実情です。日本の電車の運行ダイヤに外国の方が驚嘆するシーンと通じるものがあるかもしれません。
となると、この業務処理の自動化については実績のある従来のツールをそのまま持っていくことが候補となりますが、システムの運行を担う重要なファクタであるため、運用ツール自体の可用性の担保も合わせて考える必要があります。運用ツールに限った話ではありませんが、クラウドでの可用性担保は考慮すべきポイントが多いので注意が必要です。
可用性担保のためには一般的には冗長構成を組む形になりますが、従来のオンプレを前提とした冗長化の仕組みはサーバやOS、ストレージ、ネットワークといった基盤と密連携しているため、基盤がクラウドとなることでクラウドサービスとして提供される各コンポーネントとの連携を考える必要があります。つまり構成として変わるということと、クラウドサービスも含めた高いスキルが求められることで、初期構築は良いとしても長期の運用のなかで熟知した技術者を確保し続ける必要があるということになります。
障害が発生した際には、冗長構成により業務が継続できるとして、障害復旧や再発防止を考えるために原因分析は各コンポーネントをまたがって調査することになるので、それを行える体制を考えておくことが求められます。また、観点は異なるのですが、クラウドの従量課金がこの構成にも影響が及ぶことを嫌がるお客様もいらっしゃいました。
高い安いといった絶対額としての問題というよりは可用性担保のための費用が点在して見えづらくということでしたが、クラウドリフトと言っても一筋縄にはいかないという本質に嘆かれていた様子が印象的でした。
４．運用担当者が運用ツールを使いこなせない/振り回される
ここまで記載した通り、クラウドの利用においてはクラウドならではの運用が必要となり、クラウドサービスが用意する運用ツール、従来の運用ツール、他の運用ツールを取捨選択・組み合わせて利用していくことになります。先に申し上げると、仕様確認、業務要件とのマッピングなどの事前の調査検討では見えづらい一方で、長期にわたる安定運用への影響のある重要な課題があります。
まず、クラウドサービスが提供するツールや管理画面、他の運用ツールとして候補に挙がるクラウドと親和性の高いとうたわれるツールがありますが、これを使いこなせるかという課題です。そのほとんどは海外発のツールであり、ローカライズが不十分なものが散見されるといったところは時間が解決してくれるものと願うところですが、ここではツールの利用に一定のITスキルを要することを取り上げます。
例えば監視項目の変更をする際は、対象となるメトリクスの調査が必要となったり、独自のマクロ言語の編集が必要といった具合で、利用者を選ぶツールがあるということです。海外(特に北米)でのユーザ企業におけるIT技術者の多さについては日本との構造上の違いとしてご存じの方もいらっしゃるかもしれませんが、運用ツールが求めるスキル要件に大きく影響しているのではないかと考えます。この違いをしっかりと捉えたうえで、現状の体制強化はもちろん試みるべきとも思いますが、一足飛びには難しいことでもあるので、自社の体制にあったツールであるかを見定める必要があります。
そして、「運用ツール」がどこまで面倒を見てくれるのかという観点も重要です。クラウドリソースの制御やクラウド特有の監視など、多くの運用ツールでは導入するだけでというわけにはいかず、クラウドサービスを組み合わせたり提供されるAPIなどを駆使した「作り込み」が必要となります。問題はこの「作り込み」の維持・運用です。
実態はスクリプトで初期構築の際に有識者が作成したものであることが通例ですが、運用要件の変更の際に、これらの「作り込み」に対する変更が必要となることもあります。
また、クラウドと密連携を実現するパーツであるがゆえ、クラウド側の仕様変更への追随を常に意識する必要があります。「作り込み」をメンテナンスしていくスキルを持ち合わせ、頻繁に行われるクラウドサービスの変化に対するキャッチアップする長期の運用に組み込むことになるので、ここでもまた運用体制に対するハードルとなります。
もう一つ運用担当を悩ませる問題としては、複数のツールを組み合わせて利用すること自体にあります。運用の中でいくつものツールを見ることは運用業務の煩雑化につながるという点は、従来のオンプレ中心の運用の中でも言われてきたことで、クラウドになったからと言って変わることではありません。ただ、使うツールが変わることで改めて習熟しなければならないという点、さらに前述の通り利用に習熟のハードルが高いものもあるということも重なってしまうと、クラウドのメリットを追求するどころか安定的な運用に対するリスクともなりかねません。
数年前にまさにこの状況に陥るのではないかとお話していたお客様と最近会話したのですが、システム構成のちょっとした変更であったり、クラウドの柔軟性の活用のためにリソース変更を現在の運用体制では行えない固定的な運用になっている、ベンダーに相談するなどしているが要件整理、見積、契約といった従来通りの重い手順を踏むため、クラウドを活用しながらビジネスのスピード感を上げるという当初の目論見は全く実現できていない、と厳しい目でおっしゃっており、システムライフサイクルを前倒して見直しを検討するとのことでした。数年前に会話した当時もご理解はされていましたが明確な指標としては表現しづらいところでもあり、検討への反映が難しかったことが実体験として帰ってきた形です。
クラウド運用で考慮すべき要件
これらの課題を解決することでクラウドのメリットを享受しながらも安定的な運用が実現できることになります。各課題解決に対して必要となる要件を整理してみます。その前に、課題の中で「運用担当者に求められるスキル」がキーワードとなっています。
ここまでの文脈で、スキルが高ければ良いと思われるかもしれませんが、オペレーションコストとして跳ね返ってきますし、高スキル人材であれば運用のほかの業務での活躍も期待したくもなります。ここでは運用体制に求められるスキル要件をどこまで下げられるか、もしくは、クラウドだからと言って特別なことなく現行の体制で実現する、という前提を置きたいと思います。
１．クラウドのリソース変更・拡張の柔軟性の活用
- 業務処理と組み合わせたクラウドリソースのコントロールを行えること
- 綿密な設計に基づいたコントロールを自動的に行えること
- 利用するソフトウェアのライセンスが、関係するリソースの変動に依存しないモデルであること
サービスの開始や閉塞、カレンダにのっとったバッチ処理等の業務処理、システムのピーク性といったところと連動して、クラウドのリソース制御を行う仕組みが必要となります。また、運用中、常にこのコントロールを行いたいわけですが、常時人が実施するにはコストもかかりますし、人的作業にはミスがつきものなので自動化は必須となります。
２．クラウド上のシステムの監視
- クラウド特有の監視項目への対応
- ユーザアプリケーション等の持ち込みコンポーネントへの監視
- クラウドサービスの稼働状態に対する監視
課題のところで述べましたが、クラウドだから監視しないで良いということはもちろん無いですし、むしろ従来のオンプレミス環境にないやり方や監視対象が増えることになるので対応が必要となります。
３．自動化の核となる運用ツールの可用性担保
- 特別なスキルを必要としない運用性も考慮した簡便な冗長構成を組めること
重要な業務処理やリソース制御を運用ツールに担ってもらうことになるため、その可用性担保が重要な要件となりますが、長期にわたる運用を現行の運用体制で維持するためには技術的な難しさを極力排除した仕組みの導入が必須となります。
４．運用ツールとしての簡易性
- クラウド特有の知識を有しなくとも利用できること
- クラウドとの連携を機能と保有し、作り込みなしで実現できること
- 複数ツール利用を簡易化する仕組みを有すること
他の要件を実現する運用ツールが一つで済めばいいのですが現実は組み合わせとなります。ツールによってはクラウドの深い知識が求められるものありますし、様々なツールに習熟するハードルは是非下げたいところです。また、クラウドとの連携を機能として有しているツールであれば、維持対象となる「作り込み」が不要となりますし、クラウドの変化への追随もツールに任せることができます。
最後に、当社が提供する統合運用ソフトウェア「Hinemos」では、これらすべての課題を解決できることをご紹介いたします。自動化やクラウド連携など様々な機能を有しているのですが、すべてに関係する製品コンセプトのひとつとして「オペレータ向けのツール」であることを掲げており、ここにすべてが凝縮されると言っても過言ではありません。
クラウドがコモディティ化する以前より日本の多くのお客様の運用シーンでご利用頂いており、各種監視機能、緻密な業務処理のスケジューリングと自動化といったトラディショナルな運用機能は当然に持っておりますし、他の運用ツールより先駆けてクラウド対応を開始し、簡易な設定でクラウドとの連携を実現した機能をUIも含めオペレータ向けには従来の簡便な、裏側を意識させない使用感で提供しています。すべて機能として凝縮しているため、作り込みは不要であり、クラウドの変化への追随も当社で行いHinemosの機能に転換しております。
また、Hinemosの中核サーバを冗長化する機能も自身で持っています。この機能は非常に特徴的で、冗長化を実現するための機能をすべて持っており、別途追加の機材がほとんど不要となります。そして、オンプレミス環境、仮想化基盤上、クラウド上、どこでもこの同じ機能を利用することができるので基盤ごとの構成設計や運用手順の習熟といったことも不要です。管理対象数に依存しない価格モデルのサブスクリプション形式となっています。クラウドの柔軟性という特徴をスポイルすることなく、クラウドと連携した運用を簡易な操作感で実現できるので、是非ご検討いただければと思います。
※NTTデータ 先端技術株式会社のHinemosについて詳しく知りたい方は こちらから
まとめ
クラウド活用の広がりとともに運用の重要性は高まる一方で、残念なことに下流・後工程という従来のイメージで優先的な検討がなされていないのが現状です。さらに、元来、安定的な運用に向けて積み上げてきた実績もあり、そこからの大幅な変更には消極的な意見が出てしまうのも理解できる話ではあります。
ただ、当社でも「運用のDX」とうたっておりますが、ビジネスの営みとそれを支えるシステムの改革と日々の運用が合わさって成し遂げられるものなので、運用の上流化とともに今回あげたような課題を課題とせず、本来の目的である変革とその効果の追求を推進頂ければと思います。
※Hinemos®はNTTデータ先端技術株式会社の登録商標です。