「オンプレ回帰」が一筋縄ではいかない5つの理由【体験談】

パブリッククラウドにどっぷりと漬かったサービスをオンプレ回帰させるのは一筋縄ではいきません。今回はオンプレ回帰を求められる状況に対して、フラットに建設的に方向性を決めるための一助とすべく、事前に確認すべき5つの項目をお話します。

[久松 剛，エンジニアリングマネージメント]

情シス百物語

「IT百物語蒐集家」としてITかいわいについてnoteを更新する久松氏が、情シス部長を2社で担当した経験を基に、情シスに関する由無し事を言語化します。

　2010年代前半から始まったパブリッククラウドのブームですが、ここにきてオンプレミスへの回帰が話題になっています。

　経営層がオンプレミス事業者のカタログと見積もりを持ちながら「オンプレ回帰」を鼻息荒く迫ってくることもあるでしょう。オンプレミスとパブリッククラウドの優劣はさておき、パブリッククラウドにどっぷりと漬かったサービスをオンプレ回帰させるのは一筋縄ではいきません。

　私はネットワークインフラの研究者であったため、オンプレミスに対する思い入れはあります。加えてオンプレミスからパブリッククラウドへとシフトしたインフラエンジニアでもあります。今回はオンプレ回帰を求められる状況に対して、建設的に方向性を決めるための一助とすべく、事前に確認すべき5つの項目をお話します。

経営層がオンプレ回帰をしたがる背景

　経営層のオンプレ回帰の温度感が何を起因に高まっているのかを正確に知る必要があります。多くの場合、セキュリティとコストが挙げられる傾向にあります（参考記事1、参考記事2）。

セキュリティ

　世界情勢が悪化するにつれサイバー攻撃も増加する傾向にあります。利用者の多い「Amazon Web Services」（AWS）などはファイアウォールやクラウドストレージのアクセス権設定ミスによるサービス障害や情報漏えいが多々見受けられます。オンプレミスであっても設定ミスがあったりセキュリティ対策が不十分だったりすれば被害には遭います。

　オンプレミスの運営を信頼のおける外部企業に委託しない限り、サポートレベルにはよりますが、問い合わせ先や相談先が明確であるパブリッククラウドの方が有事の際のサポートを期待できる可能性が高いです。

円安の場合はオンプレミスの方が安い

　一般的にデータセンターを契約し、ネットワーク機器やサーバを減価償却いっぱいまで使った場合の見積もりと、同等の性能をパブリッククラウドを使った場合の見積もりを比較すると、前者のほうが圧倒的に安い傾向にあります。

　ある企業では若手エンジニアがパブリッククラウドを使いたいと言い始めると見積もりを取らせ、現状のサーバに関わるコストを見せてねじ伏せるというやり方をしています。

　私も経験があります。ある程度のボリュームのパブリッククラウドを運用していると、他のクラウド事業者やオンプレミス事業者が相見積を持って多数提案してきます。

　通常の見積もりには現れないコストを想定し、移行を検討していく必要があります。

オンプレ回帰に対して加味するべきこと

　オンプレ回帰を検討するに当たって念頭に置くべきは下記の3点です。

• どういうサービスをオンプレ回帰の対象にするのか
• 全てをオンプレ回帰するのか、部分的にオンプレ回帰するのか
• そのサービスについてどの程度の信頼性が求められるのか

　特に最後の項目については事前に経営層と合意しなければなりません。私はインフラエンジニアの面接をしていて驚くのですが、3営業日ファイルサーバが機能していなくても怒られないような企業は存在します。

　しかしこうした牧歌的なものを除くと、次に挙げるようなものを考慮する必要があります。

「環境」が壊れるリスクを考える

　オンプレミスを構築する場合、ネットワーク機器やサーバの冗長構成を取ることが一般的です。しかしどうにも厳しいのがデータセンターが提供する環境です。

　データセンターは電源が冗長化され蓄電池も完備、空調は18度程度に調整、コンピュータをホスティングしているため、水を使わない消防設備、不審者を入れないための警備員と受付などで構成されています。さながら現代における要塞（ようさい）のようです。

　しかし、どんなに鉄壁の守りを構築しても、これらが物理的に壊れるということはあります。建物の寿命は長いもののUPSと空調が鬼門です。

　過去に私が遭遇したトラブルは「空調が冗長化されておらず、一斉に止まった」というものでした。冷たい空気が流通しなくなったためサーバが次々と発熱を理由にダウンするという地獄のような光景がありました。

　また、別のデータセンターでは建設時に設置した冗長化された2台の空調がほぼ同時に壊れるということもありました。無理やりスペースを作って3機目を設置し、設置の間は業務用扇風機でしのぐという状況でした。

　UPSの場合、普段活躍する機会がないため、いざ停電したときに切り替わらなかったり、蓄電池のメモリ効果が進んでいて数分しか持たなかったりした現場を見たことがあります。

冗長化に対する予算の限界

　環境が壊れることを想定し、複数のデータセンターを契約して地理的に冗長化する選択肢も考えられます。AWSで言うところのMAZ構成や、マルチリージョン構成に相当します。自然災害に備えるという意味でも勘案してよいでしょう。

　パブリッククラウドの場合、データセンターやネットワーク機器、ハードウェアの設置や運用保守もパブリッククラウド事業者が担ってくれます。そのため、画面上でポチポチとクリックすれば関東と関西で冗長構成を構築できます。

　しかしオンプレミスは、契約形態にもよりますがネットワーク機器やサーバなどは自社で面倒を見なければならないため、データセンター内の機材設置や障害対応も現地に赴かなくてはいけません。後述する緊急対応人員なども踏まえると、地理的に遠い2拠点に担当者を置くことは結構なコストになるでしょう。

予備機材はあるか

　ハードウェアが故障した際、オンプレミスではホットスタンバイやコールドスタンバイとして予備機を用意し、入れ替えて対応する必要があります。過去のオンプレミスの対応事例でも下記のようなことがありました。

• 予備機がないので秋葉原に寄ってから向かう
• ファンが壊れたものの予備機がないので、都内のパーツショップに電話をかけ続ける
• 予備機の通電実績がなく、動かない

　いずれも1営業日近くサービスが停止する障害につながりました。見積もりを取る際にはこうした保守機材も計算に入れましょう。

マネージドサービスにどっぷり漬かっていると移行リスクが大きい

　パブリッククラウドの特徴の一つに豊富なマネージドサービスがあります。データベースから始まってプッシュ通知送信サービス、メール送信サービス、キューイングサービスなどもあります。

　かつては、こうしたマネージドサービスに相当するミドルウェアを自前で用意するのが当たり前でした。メール送信サービスを例に挙げましょう。以前は自前でメールサーバを立てることは頻繁にありました。電子メールの認証技術のDKIM（DomainKeys Identified Mail）では送信元認証のSPF（Sender Policy Framework）レコードや認証に失敗したメッセージの取り扱いを制御するDMARCなどの各種設定も必要ですし、自前で不通になった電子メールのアドレスをクレンジングする機能も実装しなければなりません。

　このあたりをあまり理解せずに設定すると、電子メールが迷惑メールに落ちてしまったり、送信が遅延したりしてサービスが滞る原因になります。

　オンプレミスからやってきた一人として強く感じるのは、各種ミドルウェアについて「何となく理解している」レベルであっても「それっぽく使える」のがマネージドサービスの強みです。パフォーマンスに問題があれば課金すればよいものがほとんどです。

　オンプレミスに回帰した場合、利用しているマネージドサービスの数だけメンバーのキャッチアップコストがかかりますし、障害が起きた際にその理解度が試されます。先の「神奈川県公立入試インターネット出願システム」のトラブルは「Amazon Simple Email Service」（Amazon SES）からの切り替えによる障害でした。このような事業リスクが発生することも加味して意思決定しなければなりません。

オンプレミスが分かる人材の確保と高齢化

　正社員でないと時間外対応は難しいものです。外部業者と24時間365日の保守契約を結べば問題はないものの、夜間や休日の障害に外部業者を呼び出せないこともあります。

　そこで正社員採用を実施し、待機手当や夜間手当、緊急対応の代休制度などを整備して乗り越える選択肢が考えられます。

　まず厄介なことに、オンプレミスに知見がある若い人が非常に少ないという事実があります。ある大手派遣会社でオンプレミスに対応できるインフラエンジニアの年齢分布を見たことがあります。

　オンプレミスを担うボリュームゾーンとしての40〜50代は、2000年のIT革命を期にISPやホスティング事業者が増加し「これからはインターネットだ」と参入した人たちです。特に就職氷河期と重なったことから、数少ない積極採用業界だったIT業界が（働き方はブラックだったものの）受け皿として機能しました。

　30代は少ない傾向にあります。2010年代前半のソーシャルゲームバブルやWebサービスの需要増加、スマホの登場によりプログラマーを志した人たちが増加したことによって、インフラエンジニアが不人気に。また、インフラエンジニアの中でパブリッククラウドがブームになったことでオンプレミスエンジニアを志す人が減少しました。

　20代は急増しています。2018〜2019年をピークにしたプログラミングスクールのブームの影響です。ITエンジニアを志すものの競争率が高く挫折。しかし30代が少なく若返りが急務であり、資格があれば受け入れされやすかったネットワークインテグレーター（NIer）を中心とし受け入れが進みました。特にプログラマーになれなかったが資格勉強は苦でなく、ITエンジニアになりたい第二新卒を中心に増加しました。

　このような背景から、オンプレミス環境を設計、構築、運用できる経験者は40代以上に絞られます。

SLIと働き方を意識するとチーム化は必須

　SLI（サービスレベル指標）が厳しいものであればインフラチームを構成する必要があります。アラートに一次対応するために3交代制で人員を貼り付けるか、MSP（マネージドサービスプロバイダー）と契約して監視体制を置く必要があります。

　緊急時に対応できるレベルの高い人を複数人採用する必要があります。過去に私がその責任を担っていたときは、インフルエンザで寝込んでいようが、有給でディズニーランドにいようが、パートナーとご飯を食べていようが、どこでも呼び出されました。

　ハードウェアの対応が必要な場合に備えて、データセンター近くに住まわせることも視野に入れなければなりません。ある開発会社に運用保守を任せていたことがありますが、ハードウェア障害が起きた際、現地に集合するだけで3時間かかったことがありました。

　もちろん、土日祝日の緊急対応が不要で、営業時間中に対応できれば十分なサービスであれば、こうした体制は小さくできます。

オンプレ回帰には多大なる覚悟が伴う

　パブリッククラウドは、インフラエンジニアが担っていたミドルウェアの専門知識から基礎的なハードウェア構築、サポート業務などをアウトソーシングしている背景があります。オンプレ回帰はこれらのコストを見越して意思決定しなければなりません。

　また、非常に厄介なのがオンプレ回帰のためにオンプレミス専用の人材を正社員採用した後、再度パブリッククラウドに回帰する意思決定をした場合です。当該人材の雇用をどうするのかという問題が残ります。

　2010年代中盤、パブリッククラウドがブームになり「オンプレミスは古い」という理解が広まったとき、各社から大量のインフラエンジニアが出ていきました。パブリッククラウドに対応するためのリスキリングができなかったケースもあれば、オンプレミスに愛があるゆえに転職したケースもあります。経営の観点では、解雇規制を盾に居座るオンプレミス人材の処遇に困っていました。

　正直なところ、パブリッククラウドに骨抜きにされた人たちには荷が重いのがオンプレ回帰です。これらのリスクを含め、それでもオンプレミスに回帰するのであればよいのではないでしょうか。

著者プロフィール：久松 剛（エンジニアリングマネージメント　社長）

　エンジニアリングマネージメントの社長兼「流しのEM」。博士（政策・メディア）。慶應義塾大学で大学教員を目指した後、ワーキングプアを経て、ネットマーケティングで情シス部長を担当し上場を経験。その後レバレジーズで開発部長やレバテックの技術顧問を担当後、LIGでフィリピン・ベトナム開発拠点EMやPjM、エンジニア採用・組織改善コンサルなどを行う。

　2022年にエンジニアリングマネージメントを設立し、スタートアップやベンチャー、老舗製造業でITエンジニア採用や研修、評価給与制度作成、ブランディングといった組織改善コンサルの他、セミナーなども開催する。

Twitter : @makaibito