• HOME
  • プロローグ
  • 運用設計を「しない」トレンド!?:現場のプロが語ってみる(6)

運用設計を「しない」トレンド!?:現場のプロが語ってみる(6)

IIJの福原です。クラウドやコンテナなどの新しいテクノロジーが登場し、システム運用の現場にも影響しています。特徴を見ながら、賢く付き合っていきたいですね。最近とこれからの話を少しすると、重要な運用設計ですが、段々と設計をしない方向へ進んでいる気がしています。「しない」というより、「する」ことの範囲や意義が変わっているといった方がいいかもしれません。

クラウドやコンテナなど、次々に登場する新技術

今は、さまざまな用途でクラウドサービスが広く使われています。主要なサービスは、パブリッククラウドと呼ばれる、Azure(Microsoft Azure)やGCP(Google Cloud Platform)、AWS(Amazon Web Services)の3つ。
クラウドサービスなら、インフラから構築するよりも、ボタンをポチっとやるだけで簡単に設定して使い始められて、便利ですよね。同じようなシステムなら、基本部分は共通化できます。IaaS(サービスとしてのインフラ)やPaaS(サービスとしてのプラットフォーム)は、いろいろ構築しなければなりませんが、SaaS(サービスとしてのソフトウェア)ならそのまますぐに使えます。IaaSからPaaSに、PaaSからSaaSに変わっていくと、ユーザがやるべきことは減っていく一方、クラウドサービスのベンダ側には負担がどんどん増えていきます。従来はハードウェアとして見たり触ったりできて、ある意味分かりやすかったのに対して、全く目に見えない新しい技術を覚える必要があります。

マルチクラウド時代のSaas、PaaS、IaaSを改めて復習しよう
https://un4navi.com/prologue/19004/

クラウドサービスを自由に使えるのはとても便利ですが、「野放し」にすると今度は煩雑になって仕事がし辛くなってしまいます。そうならないためには、適切な運用と管理が欠かせません。
ただ、クラウドサービスには大きな弊害があって、使い方を限定してしまうと、全く新しい機能が使えないんです。クラウドサービスのメリットを活かして新しいことをどんどん手軽にトライしていく使い方と、運用を標準化して横展開していくスタイルは相容れないので、現場の鬩ぎ合いは今後も続いていくでしょう。
また、これらのクラウドサービスの仕様も、必要に応じて変更されるので、システムを開発した時点と、障害が起きた後に復旧させる時点とで、仕様が微妙に変わっていることもあります。コンテンツのアップデートなら、表示される中味が変わるだけなので、システム運用上の大きな影響はほとんどありません。ただこれが、クラウドの機能追加や変更、システム構成の仕様変更だったりすると、運用も知らないわけにはいきません。業務が忙しいと、仕様の細かな変更点までキャッチアップできないのは、残念ながらよくある話。もちろん、大きな変更であれば重要なので見逃すことはありませんが、細かい変更なら無視していいわけではないので、いずれにしても注意は欠かせません。

Azure/GCP/AWSの各クラウドとニーズ:現場のプロに聞いてみた(3)
https://un4navi.com/interview/19065/

他にも、新しい仮想化技術として、コンテナが使われる場合も増えています。しかし、コンテナで開発のトライ&エラーのサイクルがいくら速くなったとしても、それに運用も付いていくことは、簡単にはできません。コンテナ自身が、自分の中で動くプロセスを監視できるので、コンテナ側に任せてしまうのが妥当です。それをわざわざ、運用側で監視する必要はないですから。

コンテナとそれを管理するDockerはシステム運用にどう影響する?
https://un4navi.com//prologue/19043/

<PR>オンプレミスからマルチクラウドの組み合わせに変わると、運用管理が煩雑に…さてどうしますか?そんな面倒は、SaaS型の統合運用管理サービス「UOM」にお任せで楽に運用!詳しくはこちら

運用設計は重要でも、設計しない方向へ!?

システムの運用設計は昔からある業務ですが、近年では、徐々に運用設計をしない方向にシフトしています。もちろん、本質的に運用設計が重要なことは変わりませんが、見るべき範囲が変わってきているといった方がいいかもしれません。対象が、監視や運用部分だけを設計するというより、システム全体をより広い範囲に目を向ける必要が出てきています。
私が、運用設計をしない方向にシフトしていると感じている背景の一つは、時間です。システム開発のサイクルが本当に短くなり、運用が追いついていくのはどこも本当に大変です。もちろん、スキルを持つエンジニアが絶対的に不足していることもあり、運用設計に十分な時間が掛けられない実情もあります。
そしてもう一つは、システム環境の多様化・複雑化です。オンプレミスが主流だった時代は、サーバやネットワーク機器などのハードウェアを自分たちで用意する必要がり、簡単にはサーバの台数を追加したりできませんでした。組織としても、費用対効果の観点から、冗長化も簡単にはできませんでした。
それが、クラウドサービスが広く使われるようになって、冗長化もほぼ必要なくなりました。というのも、クラウドサービス自体が、冗長化されて提供されているからです。むしろ、多重化した方がいいのではないか?しかし、『多重化するぐらいだったら、いっそ、壊れたら捨ててしまえばいいのでは?』といったレベルの、大胆な設計思想に切り替えることもできます。この発想はやや極端かもしれませんが、場合によってはありかもしれません。

次回は、いよいよ連載の最終回です。これからのシステム運用設計に必要な視点について、私なりにまとめてみましょう。最後までお付き合いよろしくお願いします。

【前回までの連載内容はこちらからご覧いただけます】

【連載1】運用設計って一体どんな仕事なのか?:現場のプロが語ってみる(1)
【連載2】正解がない運用設計という「思想」:現場のプロが語ってみる(2)
【連載3】設計に至る運用エンジニアのキャリア:現場のプロが語ってみる(3)
【連載4】運用エンジニアのマインドと存在意義:現場のプロが語ってみる(4)
【連載5】職人技だからこそアウトソース可能!:現場のプロが語ってみる(5)

IIJ_福原亮株式会社インターネットイニシアティブ
システムクラウド本部
クラウドサービス3部 副部長 兼 M&Oサービス開発課長
福原 亮

<PR>「運用設計が、システム全体を俯瞰するスタイルに変わっていくなら、細部はどうすればいいの?そこで、SaaS型でカンタン導入できる、統合運用管理サービス「UOM」!
詳しくはこちら

 

関連記事一覧