こんにちは。レッドハットコンサルティングチームの木嶋です。
「アプリケーションモダナイゼーション(以下、モダナイゼーション)」について解説する連載は、前回である8回目からリファクタリング (Refactor) をテーマにしています。
リファクターは『既存の振る舞いを保ちながら、内部構造を改善する』行為です。これ自体はユーザーに目新しいものはなにも生み出さないので、一見ただの「作り直し」に見えてしまいます。
しかし、内部構造の改善は最終的に、開発者や運用者の時間の使われ方と、組織全体のコスト構造を大きく変えます。見た目以上に「経済の話」なのです。
前回はリファクタリングを開発者 (Dev) 視点 から捉え直し、「本当に欲しい機能の開発に使えている時間は限定されている」ことのデメリットを経済適合性の観点で整理しました。
本記事では、このリファクタリングを 運用 (Ops) 視点 から見直し、一見オーバースペックに見える「マイクロサービスアーキテクチャ」がなぜ採用されるのかを見直していきます。
- はじめに
- マイクロサービス化適合性アセスメントから見える現実
- Opsの現実
- 運用回避依存の罠
- Ops視点でマイクロサービスアーキテクチャを選ぶ3つの理由
- でも、マイクロサービスアーキテクチャって運用が大変なんでしょう？
- まとめ
- おまけ
はじめに
前回のDev編ではあえてマイクロサービスアーキテクチャを大きく取り上げませんでした。
開発 (Dev) 視点だけで見ると、実はマイクロサービスを選ばなければならない決定的な理由はあまり大きくありません。開発のスピードが経営課題になりうる組織、および対象システムが日本の組織にどれだけあるでしょうか。
一方で、運用 (Ops) の視点に立つと、マイクロサービスがもたらす価値は一気に明確になります。
- 障害の局所化
- キャパシティ課題への対応
- デプロイ、リリースのための準備と変更管理の最小化
- 属人化と運用品質リスクの低減
ただし残念ながら日本の大きな組織では、開発 (Dev)、運用 (Ops)、システムオーナーがそれぞれ別会社という構造の組織が多く、Opsが気がついている運用的課題、解消するための工夫や効果のでにくさが、Devやシステムオーナーのところに届きにくく、結果として全体最適を目的とした効率化が進みにくいという課題が生じがちです。
ではOpsでは日々何が起きており、どんなことに現在最も高価な人的リソースを割いているのでしょうか。 そしてそれはなぜうまく効率化されないのでしょうか。
ここからはこの観点に着目して掘り下げます。
マイクロサービス化適合性アセスメントから見える現実
私は、リファクタリングをしたいものの「マイクロサービスアーキテクチャが妥当かどうかわからない」というお客様のためにシステムの総合的なアセスメントをご提供しています。
この時、OSやミドルウェアやサポート期限、開発現場の悩み、いわゆる「2025年の崖」への懸念や対応の遅れといった論点は、最初のミーティングから必ずといってよいほど挙がってきます。
いずれも重要な観点ですが、一方で意外なほど話題に上がらず、こちらからお願いをしても最後まで出てこないものがあります。
このシステムは現在のトラフィック傾向に対して、どの程度のキャパシティの余力を持っているのか
例えば以下のような問いです。
- ピーク時の CPU、メモリ、DB I/O が、どの程度のマージンで推移しているのか
- トランザクション数やデータ量の増加に、あと何年・何倍耐えられるのか
- 新しいチャネルやサービスを追加したとき、どこが先に限界を迎えそうか
こうした問いに対して、きちんと数値と構造で答えられるケースは、驚くほど多くありません。 代わりに次のような回答が返ってくることがほとんどです。
- SLAはクリアできています
- 大きな問題は起きていません
そこで私は、少し問いの角度を変えて以下のように投げかけるようにしています。
- 「夜間バッチはありますか。夜間バッチは予定通りの時間枠の中で終了していますか」
- 「夜間バッチのエラーはどの程度発生しますか」
- 「システム的な繁忙日はいつ、どの時間帯ですか。その時はアクセス集中によるレイテンシー問題や障害は発生していませんか」
- 「それ以外の期間や時間帯は、繁忙日と比較してどの程度少ないですか。数分の1とか、数百分の1とか、大まかな感覚で構いません」
この4点をお聞きすると、多くの場合「実は...」とキャパシティに対する問題が出てきます。 つまり問題がないのではなく、「リファクタリング検討チームの関心事に含まれていない」ことがわかります。
このように、案外Opsの現実はしばしば、 「関心を向けるべきなのに、誰もはっきりと持ち場になっていない領域」として盲点になってしまっています。
そして皮肉なことに、この領域が日本の大きな組織において「マイクロサービス化を検討すべき、もっとも強い理由」を内在していることが少なくありません。
では、Ops の現場では日々どのようなことが起きており、 その中でキャパシティや安定運用に関する“見えないコスト”がどこに潜んでいるのでしょうか。
次に、もう少し具体的な日常の風景を見ていきます。
Opsの現実
では、Ops側の人手と時間は実際の現場でどこに費やされているのでしょうか。
Opsチームの方にお話をお伺いすると、以下のような現実が浮かび上がってきます。
- サーバーごとに運用手順が異なる
- 「アラートが上がったサーバーはどのマニュアルを参照するか」のマッチングに時間がかかる
- サーバー一覧の更新は手動だが、たまに最新情報が反映されていない
- アラートが上がって初めて「このサーバー構成、資料と違うのでは」と気づき、有識者を探しにいくこともある
また以下のように高度に属人化された様子も伺うことができます。
- 配属1-2年目はひよっこ、5年目くらいでやっと独り立ち、ベテランは20年選手
- 同じアラートが上がっても、対応手順の特定までに、新人とベテランで15分以上の差が出る
Opsのリーダー層の方々も別にこの状況を放置しているわけではありません。むしろ逆で
- この高度に属人化した中でもサービス品質を安定させるための、パッチ的な仕組みづくりで手一杯
- 運用自動化のミッションは与えられているものの、サーバーごとに運用手順が異なり、自動化しようとしても例外処理だらけになってしまい、なかなかメリットが出ない
といったジレンマを抱えているケースが多くみられます。
結果として、最も高価な人的リソースであるOpsの時間は、
- アラート対応と一次切り分け
- サーバー／マニュアル／台帳の「すり合わせ」
- サービスを止めないための場当たり的な工夫
- 新人 (?) 教育
にほとんど使い切られてしまい、本来取り組みたい構造的な改善や提案、現状維持をした場合のシステムリスク分析に回す余力が残りません。
その一方で、月次報告ミーティングは「今月も SLA は達成しました」という一言で締めくくられがちで、そこに至るまでにどれだけの人手と時間を燃やしたのかは、数字にはほとんど現れません。
運用回避依存の罠
ここで思い出していただきたいのは、前回の記事で取り上げた、価格構造の変化による「良い設計」の変遷です。
かつてCPUやメモリ、ディスクなどのコンピューティングリソースは非常に高価でした。 そのため、何か問題が起きた時、あるいは将来的な問題を見越して
- ハードウェアを増強する
- システム構成を大きく変える
といった手段は、そう簡単には選べませんでした。
代わりに選ばれてきたのが、次のような「運用でなんとかする」アプローチでした。
- 夜間バッチの監視を人手で行う
- エラーが出た時の「再実行手順」や「再起動ナレッジ」を運用でカバーする
- 繁忙期だけ一時的に増強する
いわゆる「運用回避」と呼ばれるパターンで、当時はコンピューティングリソースが高価だったからこそ、これがもっとも現実的で、費用対効果の良い選択肢でした。
リファクタリング検討チームの関心事からこういった論点が抜け落ちてしまうのは、当時の前提に立てば、合理的な判断だといえます。
しかし現在は状況がすっかり逆転しています。
- コンピューティングリソースは劇的に安価になり、必要に応じて余裕を持って積んでおくことが現実解になった
- 自動化技術が高度になり、「必要な時に短時間だけ一時的に」増強する、あるいは調子が悪くなったコンポーネントを瞬時に立ち上げ直すことが、現実的な選択肢になった
- 一方で、熟練したOps人材の時間と採用・育成コストは、相対的に非常に高くなった
にもかかわらず、かつてと同じ感覚で
- 「まずは運用でカバーする」
- 「構造を変えるのは最後の手段にしよう」
という意思決定を続けてしまうと、そのツケは人的コストと運用品質リスクのかたちで静かに積み上がっていきます。
かつては正しかったこうした「運用回避」の発想が、今やOpsの時間をじわじわと食い潰す構造的な罠になっている。ここが、現在のモダナイゼーションやリファクタリングを考える上での重要なポイントです。
Ops視点でマイクロサービスアーキテクチャを選ぶ3つの理由
これまでみてきたような「運用回避依存の罠」から抜け出すために、マイクロサービスアーキテクチャはどのような役割を果たせるでしょうか。
Ops視点で整理すると、マイクロサービスを選ぶ理由は大きく次の3つに分けられます。
人的コストを削減し、自動化しやすい構造を作る
いわゆる「SRE (Site Reliability Engineering)」に繋がる領域です。
例えばあるお客様の事例では、「運用業務の95％は自動化されており、残りの5％だけは、手動で実施した方が効率が良いのであえて人がやっている」というお話を伺ったことがあります。
ここまで自動化できる組織のSREは、従来のOpsとは役割の重心が異なります。 イメージとしては、運用手順をドキュメント化するだけでなく、その手順自体をコードとして実装し、継続的に改善していく姿に近いでしょう。
ただし、このような自動化を進めるためには、前提として アーキテクチャレベルで運用パターンをそろえておくこと 自動化しやすい単位でシステムを分割しておくこと 自動化に適した技術スタックと、コンポーネント内部の作り (12-Factor等) を採用すること が必要になります。
マイクロサービスアーキテクチャやIaC (Infrastructure as Code)、OpenShift等のコンテナ管理基盤は、まさにこの条件を満たすための選択肢として採用されます。
つまり、「人が頑張って守る運用」から「構造とコードで守る運用」へとシフトするための土台として、マイクロサービス化が位置づけられるわけです。
こうして自動化の土台が整うと、Ops や SRE の役割も「障害対応の最前線」から、「システム全体の安定性と改善をデザインする仕事」へとシフトしていきます。
キャパシティ計画の戦術の骨格を作る
キャパシティ計画を健全に行うには、「戦略的にどこにどれだけのキャパシティを割り当てるか」を考え、それを実現できる構造が必要です。
お客様環境のアセスメントをさせていただくと、キャパシティのボトルネックは、ほとんどの場合で DB に集中しています。
しかも、DB に含まれる多くのテーブルのうち、本当に問題になるのはごく一部の「非常によく使われるテーブル」だけ、というケースがほとんどです。
ところが単一モノリス構成で、DB がいわゆる「統合 DB」になっている場合、この一部のホットなテーブルのために、システム全体の DB キャパシティや並列度を大きく引き上げざるを得ません。
いくらコンピューティングリソースが安価になったとはいえ、このやり方では「使われていない部分」にもリソースを盛ることになり、どうしても無駄が目立ってしまいます。
リソース効率を上げ、無駄を減らすには、
- よく使われるテーブルだけを対象に、データ利用目的ごとに最適な形にして分割する
- その利用目的ごとに必要なキャパシティに応じてスケールアウトできるようにしておく
という戦術が取れるようにしておくことが有効です。
この文脈でのマイクロサービスアーキテクチャの採用は、同時接続数やCPU、メモリ等を利用目的ごとにアプリケーションレベル、およびデータストアレベルで観測し、よりピンポイントで効果の高い戦術の実行を可能にします。
SLAを「偶然ではなく戦略的に」担保する
「運用回避の罠」を繰り返すと、そのツケは人的コストと運用品質リスクのかたちで静かに積み上がっていきます。 積み上がったシステムのお守りをしている Ops は疲弊しており、
- 夜間・繁忙期の人的オペレーションでなんとか止めずに回し
- 月次のレポートでは「SLA 達成」とだけ報告し
- その裏で起きている“綱渡り状態”について、改善提案を出す余力が残っていない
といった状況に陥りがちです。
ここで本来問うべきなのは、次の 2 点です。
- SLA を守るために、どれだけの人手と時間を燃やしているのか
- その人手と時間に、経済的合理性はあるのか
モノリス構造のままでは、障害や変更の影響範囲が広く、 結果として「とにかく慎重に扱う」以外の選択肢を取りづらくなります。
つまり、SLA を守るためのコストとリスクを、人の努力以外でコントロールする手段が乏しいのです。
この文脈でマイクロサービスアーキテクチャを採用すると、 SLA を守るための“前提条件そのもの”を、アーキテクチャ側でデザインし直すことができます。
例えば：
- 障害箇所をサービス単位に分割し、「どこまで止まるか」をコントロールできる
- 重要度の高いサービスと、そうでないサービスで、優先順位や復旧目標(SLO)を分けやすくする
- 変更・リリースの影響範囲やロールバック単位を、サービスごとに小さく保ちやすくする
- Observability (可観測性) を活用し、SLA の遵守状況をリアルタイムなデータとして把握・判断しやすくする
外向きの SLA の数値が同じであっても、
- 「SLA は守れているが、そのために毎月誰かが燃え尽きている」状態 と
- 「SLA は守れているし、Ops メンバーもきちんと夜安心して眠ることができる」状態 では、
ビジネスとしての健全性も、広い意味での事業継続性も、まったく異なります。
マイクロサービスを Ops 視点で選ぶ 3 つ目の理由は、SLA 達成を現場の頑張りと偶然に任せるのではなく、人手だけに依存せず、アーキテクチャ設計・自動化・基盤の仕組みを組み合わせて戦略的に担保できる状態に変えるためと言えるでしょう。
でも、マイクロサービスアーキテクチャって運用が大変なんでしょう？
ここまでOps視点でのメリットをお話ししてきましたが、ここまで読んでくださった方の頭にはある「大きな疑問」が浮かんでいるのではないでしょうか。
「言いたいことはわかる。でも、サービスが細かく分かれれば、その分だけ管理対象が増えて、結局運用は大変になるんじゃないの？」
おっしゃる通りです。確かにシステム構成図上の「見た目の複雑さ」は増します。
しかし、ここで重要なのは、「どのような種類の複雑さを選ぶか」という選択です。
モノリスなシステムは、構成図はシンプルですが、一度トラブルが起きると「どこで何が起きているか」が外からは見えにくく、原因究明にはログの山と格闘し、ベテランの勘と記憶を頼りに推理するしかありません。
これは、「人手と脳内で管理しなければならない複雑さ」が高い状態です。
一方でマイクロサービスアーキテクチャは、ドメイン駆動設計 (DDD) 等で適切に境界が定義されている前提であれば、構成要素は多いものの、通信や依存関係が明確です。
ここに「Observability (可観測性)」の技術を組み合わせることで、これまでブラックボックスだった内部の動きやボトルネックを徹底的に可視化することができます。 「どこで詰まっているか」「どのサービスがエラーを吐いているか」が、人の勘ではなく、ダッシュボード上の事実として即座に特定できる状態を作れるのです。
つまり、マイクロサービス化とは、運用の複雑さを「人の頭の中(暗黙知)」から「仕組みと構造(形式知)」へと引っ張り出す転換なのです。
運用の安定を「ベテランの勘と偶然」に頼る世界から脱却し、「可視化された根拠と仕組み」へと昇華させる。 一見大変そうに見える道のりの先に、Opsが本来手に入れたかった「枕を高くして眠れる夜」が待っています。
まとめ
前回と今回の記事をお読みくださったみなさま、本当にお疲れさまでした。 「思ったより技術の話が出てこないんですけど！」と思った方もいるかもしれません。
リファクタリングは一見すると「利用者から見える新しい機能は増えないのに、お金と時間だけかかる取り組み」に見えます。 しかしその本質は
- Dev 側では「新しい価値を生むコーディング時間を取り戻す」ための投資
- Ops 側では「人が燃え尽きないかたちでサービスを守り続ける」ための投資
と捉えるのが自然です。
RehostやReplatformだけでは、これらの構造は本質的には変わらず、システムにかかるコスト構造や、人的リソースへの依存度に与えられる影響はどうしても限定的です。 どこまで構造を変えるべきか、どこまでを既存のまま許容するか、その判断は個々の技術要素の優劣ではなく、
- どれだけの人的コストと運用品質リスクを、今後も背負い続けるのか
- どこまでを人の頑張りからアーキテクチャと自動化に置き換えるのか
という観点から決めるべきテーマです。
リファクタリング案件では、よく「どの技術を採用すべきか」「どのアーキテクチャパターンが正解か」といったご相談をいただきます。
また、リファクタリングの予算を獲得するための説明や、一つ一つの意思決定に悩まれるケースも少なくありません。
その理由はシンプルで、「正解」が技術領域の中だけには存在しないからです。
これらは本来、「事業継続マネジメント (BCM)」の一環として考えるべきテーマであり、経営に近いレイヤーの判断が必要な領域です。
前回・今回の記事では、その点を意識して書いてみました。今後、リファクタリングプロジェクトの方針や予算訴求で迷うことがあれば、ここで挙げた観点を「ネタ帳」として参照していただければ幸いです。
本シリーズ次回の記事は、前回と今回の記事で触れた技術を深掘りしてみたいと思います。
おまけ
最後に、少し個人的な「未来予測」を添えさせてください。
ここ最近、「マイクロサービスは複雑すぎる」という揺り戻しもあり、トレンドとしては少し落ち着きを見せている (あるいは幻滅期にある) と言われています。
しかし私は、今後マイクロサービスアーキテクチャは、生成AI (GenAI) の活用と共に、再び脚光を浴びることになると予測しています。
理由はシンプルです。
今回お話しした「明確な境界」と「構造化された仕組み」を持つマイクロサービスの世界は、GenAI と極めて相性が良いからです。コンテキストが明確に分割され、インターフェースが定義されている環境は、AI がコードを理解し、自律的に支援を行うための理想的な遊び場 (Playground) でもあります。
逆に言えば、長年の歴史的経緯やさまざまな事情が地層のように折り重なってできあがった巨大なモノリスを、魔法のように読み解いてくれる AI は、少なくとも近い将来には現れないだろうと考えています。
人間にとって歯ごたえがありすぎる対象は、GenAI にとっても同様に負荷が高く、期待できるアウトプット品質にもおのずと限界があります。
今の苦しみを解消するための構造化投資は、来たる AI 共存時代への「入場チケット」でもあります。来年の今頃、あるいは再来年の今頃、この予測の答え合わせができるはずです。そういう意味でも、このアーキテクチャスタイルは、今こそ再注目に値すると考えています。
