【CNDW2025】EoL対応に振り回されないために 老舗SaaSの現場がたどり着いた主導権を握る運用戦略

CloudNative Days Winter 2025で行われたセッション「老舗SaaS運用の舞台裏～AWS EoL対応地獄から「主導権」を奪還するまでの道のりと教訓～」では、クラウド時代のSaaS運用が直面する現実的な課題が語られた。登壇したのは、株式会社イルグルムの開発本部 基盤開発部 みらい基盤課の山本瑛治氏。20年近く運用されてきた老舗SaaS「AD EBiS」をAWSへと移行する中で、EoL対応に翻弄され続けた現場が、いかにして受け身の運用から脱し、主導権を取り戻していったのか。

老舗SaaSのクラウドシフトがEoL管理を避けられなくした背景

クラウドに移行すれば運用は楽になる──。少なくとも、そう信じられてきた。しかし現実には、AWS上で長期運用されるSaaSほど、EoL対応という終わりのない課題に直面することになる。セッションでは、20年近く運用されてきた老舗SaaS「AD EBiS」を題材に、AWSのEoL対応に翻弄され続けた現場が、いかにして運用の主導権を取り戻したのか、その泥臭い過程と教訓が語られた。

山本氏が携わる広告効果測定ツール「AD EBiS」は、月間15億リクエストを処理する大規模SaaSであり、サブシステム単位で分割されたアーキテクチャによって高い可用性とスケーラビリティを実現してきた。2015年頃から段階的に進められてきたクラウドシフトは、10年という長い時間をかけて最終局面に到達している。

その過程で浮き彫りになったのが、クラウドならではの運用課題である。コスト管理と並び、とくに深刻だったのがEoL管理だ。山本氏は冒頭で「皆さん、EoL対応していますか。クラウドにおけるEoL対応、つらくないですか」と問いかけ、その重さを率直に語っている。

EoLとは、ミドルウェアやプログラミング言語、マネージドサービスなどが公式サポートの終了を迎えることである。EoLを迎えたソフトウェアは、セキュリティリスクや保守負担の増大を抱えるため、運用を続ける以上、必ず対応が必要になる。環境ではこのEoL対応が、従来以上に頻繁かつ強制力を伴って現れる点が特徴だ。

EoL/EoL対応とは？：EoLとは？

セッションで語られたのは、EoLそのものの定義ではない。EoL対応が日常化したクラウド時代において、いかにして運用の主導権を失わず、プロダクトと組織の健全性を保つのか。その核心となるのが「EoL管理」であり、その現実と教訓が掘り下げられていった。

AWSに見るEoL対応が運用と意思決定を縛る構造的課題

EoL対応自体は特別な作業ではない。AWSから届く通知を起点に、対象リソースと影響範囲を確認し、修正や検証、リリース計画を立てて進める。山本氏も「いわゆる開発プロジェクトと同じ進め方です」と説明する。

しかしAWSにおけるEoL対応には、オンプレミス時代にはなかった前提がある。それは「塩漬けができない」点だ。AWSではサポート期限を超えると、サービス側で強制的にバージョンアップが行われる場合があり、非互換変更による障害リスクを避けるため、EoL対応を先送りする判断は現実的ではない。

AWSにおけるEoL対応の課題：課題

この結果、一定期間ごとに必ずEoL対応が発生し、優先度を下げることもできない。山本氏は、この状態が「ビジネスアジリティの低下」を招くと指摘する。プロダクトの機能改善や新規開発よりも優先されがちなEoL対応が、組織のリソースを継続的に消費していくからだ。

そこで示された対応方針が「主導権を握る」という考え方である。AWSからの通知を待って動くのではなく、どの時期にどのEoL対応が発生し、どれほどの工数が必要になるのかを事前に整理し、計画として管理する。「通知が来てから動くと、どうしても後手に回ってしまいます」という山本氏の言葉が、その本質を端的に表している。

AWSを例に語られているものの、この課題と方針は、クラウド上で長期運用されるSaaS全般に共通するものだ。この視点が、次章で語られる具体的な試行錯誤の前提となっている。

EoL対応地獄から主導権を取り戻すまでの教訓

ここからは、AD EBiSの運用現場で実際に経験したEoL対応の変遷を、四つのフェーズに分けて振り返る。重要なのは出来事そのものではなく、各段階で得られた教訓である。これらはAWSを例に説明されているが、すべてのクラウド上でSaaSを長期運用する現場に通じるものだ。

・移行期──クラウド思想を理解せずに進めた代償

クラウドシフト初期は、最新のOSやミドルウェアを採用し、EoLを強く意識する必要もなく順調に進んでいた。しかしこの時期の最大の教訓は、クラウドの思想を十分に理解しないまま移行を進めてしまった点にある。

山本氏は「オンプレミスの思想をそのままクラウドに持ち込んではいけません」と語る。とくにライフサイクルの短い言語やミドルウェアについて、EoL対応を前提とした設計や運用を考えていなかったことが、後の負担を増幅させた。初期段階での設計判断が、数年後のEoL対応コストを大きく左右するという認識が、このフェーズの教訓である。

・混乱期──EoL対応は技術よりも組織を試す

クラウド移行から数年後、複数のEoL通知が短期間に集中して届いた。数百規模のLambdaや大容量データベースのバージョンアップを、限られた期限内に本番環境で対応する必要が生じ、現場は混乱に陥った。進行中だったプロダクト開発を止め、EoL対応を最優先せざるを得ない状況に追い込まれた。

山本氏は当時を「正直、阿鼻叫喚でした」と振り返る。このフェーズで得られた教訓は、EoL対応の本当の難しさは技術ではなく、工数と予算をどう確保するかにあるという点だ。緊急対応であっても、過去事例やリスクを示し、「今対応しなければどれだけの損失が出るのか」を説明できなければ、組織は動かない。この現実を直視することが、次の段階につながった。

・改善期──小さな改善を積み重ねるという決断

混乱期を経て、EoL対応は一過性のイベントではなく、定期的に発生する運用作業だと認識が変わる。そこで始めたのが、ドキュメント整備や手順の標準化、知見の共有といった小さな改善だった。

山本氏は「小さくても改善を積み重ねることが大切です」と語る。さらに重要だったのは、改善に取り組むと決めることだ。「判断するだけでは改善は進みません。先に決断する必要がありました」という言葉が示す通り、改善のための時間を確保する意志そのものが、EoL管理を前進させた教訓である。

・平穏期──EoLを管理可能な運用へ変える

改善を積み重ねた結果、EoL対応は突発的な負担ではなく、計画可能な運用作業へと変わっていった。直近1年のEoL対応を見通せるようになり、さらに数年先を見据えた計画を立てることで、予算やリソース調整にも余裕が生まれる。

山本氏は「ようやく主導権を握れたと感じました」と語る。EoL対応そのものはなくならないが、受け身で振り回される状態から脱し、主体的に管理できるようになった。この到達点こそが、クラウド時代のEoL管理における現実的なゴールだと言える。

具体的な対応の変遷：平穏期

EoL対応と向き合い主導権を握るための最終的な決断

セッションを通じて語られたEoL対応の話は、特別な成功事例ではない。むしろ長期運用されるSaaSであれば、誰もがいずれ直面する現実を、正面から言語化したものだと言える。AWSを例に示されたEoL対応の課題は、クラウド上で運用されるサービス全般に共通する構造的な問題であり、避けて通ることはできない。

重要なのは、EoL対応そのものをなくすことではない。EoLは必ずやってくる。その前提に立ったうえで、通知に振り回される受け身の運用を続けるのか、それとも計画と管理によって主導権を取り戻すのか。その選択が、ビジネスアジリティや組織の健全性を大きく左右する。

移行期の設計判断、混乱期の苦い経験、改善期の小さな積み重ね、そして平穏期に至るまでの変遷は、一足飛びに辿り着けるものではない。銀の弾丸はなく、地道な運用と改善を続けるしかないという現実も、山本氏は率直に示している。しかし同時に、主導権を握ることは不可能ではないという事実も、このセッションは伝えている。

EoL対応は、技術の問題であると同時に、意思決定の問題でもある。何を優先し、どこに時間とリソースを割くのか。その判断を先送りにせず、一歩踏み出すことが、次の数年の運用を大きく変える。

山本氏は最後に、聴衆へこう問いかけた。「もしセッションを聞いて響いたところがあれば、ぜひ、今この瞬間、決断してみませんか？」