データセンターと私、私とデータセンター

こんにちは。

株式会社medibaの曽根と申します。

バックエンドのエンジニアとして入社し14年。
開発部門やインフラのマネージャーを経験し、現在はCTO準備室室長補佐 兼 アウトソースUNITマネージャー 兼 auサービスプロダクトマネージャー、という肩書をいただいております。

さて、mediba advent calender も最終日。
バラエティに富んだ内容を私も楽しませていただきました。

今年はコロナ影響もあり、みなさん「家での過ごし方をどう楽しむのか?」というのは色々工夫されたことだと思います。
個人的にはゴールデンウィークを利用して息子とミニ四駆のコースを自作したのですが、
Satoshi Takeda の記事を読み、「制作過程の写真をちゃんと撮ってない俺の馬鹿。超馬鹿、俺」と思ったのが今年の思い出です。ああ、悔しい。

画像1

興味のある方はプラダンボールを利用した自作ミニ四駆コース、というのを検索してもらうとよいのですが、私のは

・分解&組み立てができる
・2レーンあり立体交差する

という点でオリジナリティ、創意工夫に溢れた作品となっており・・・って写真撮っとけよ俺の(略)


はい。ということで本題に入りたいと思います。
今回は「データセンターと私」ということでタイトルは @kitatubaの記事
 のオマージュとなっておりますが
このクラウド全盛時代において未だに残る、弊社のオンプレインフラの歴史と事情を解説してみましょう。

今は昔

かつて(どの会社もそうだとは思いますが)、medibaではほぼ全てのサービスをデータセンターで運用していました。
一部レンタルサーバ、ホスティング等を利用するケースもありましたが、KDDIシステムとの連携や(当時は専用線が必要なシステムがあったり)
求めるサービスレベル(稼働率など)を考慮するとそれ以外に選択肢はなかったと言えるでしょう。

2010年代の中頃から、medibaでもクラウド(メインはAWS)を商用利用するようになり、構築スピードと運用フェーズでの柔軟性の高さからクラウドを選択するケースが多くなりました。
多くなりました、というより意図的に「新規システムはクラウドで」と方針を転換したという言い方が正しいでしょうか。

もちろん、現在においてもシステムや事業の特性や規模によりオンプレミスを選択する企業も多いとは思いますが、これはいわゆる「持ち家が得か賃貸が得か」議論のようなもので、今回は割愛します。medibaにとってはその選択がベスト、という判断でした。

運用中、稼働中のサービスにおいても、EOSL(ハード、ソフト、ミドルウェア、フレームワーク等)を契機にシステムをリニューアル、クラウドへの移設が次々に行われました。

過渡期

全盛期はmedibaが契約しているデータセンターで数十のサービスが稼働。
運用費(場所やラック等の設備費用、ハード保守費、回線費etc..)は月に数億円の規模でしたが、多くのシステムをそこで運用することでスケールメリットを出していました。

クラウド移設により、この設備から「出ていく」システムが増えるとどうなるでしょうか?

ハードウェアの保守費用など、サーバ毎/システム毎にかかる費用は移設と共になくなる(除却というやつですね)ことでその後のランニング費用は不要になりますが、設備費用や回線費用などは基本的に継続してかかります。

マンションを運営していて次々住人が出ていった状態を想像してもらうとわかりやすいでしょうか。共益部分のランニング費用はかかりつづけ、家賃収入が減っている状態ですね。

(やたらと不動産に例えたがるのは私が引越しを検討しているからです。ご了承ください)

集約に次ぐ集約

さて、この状態を放置しておくわけにはいかないのでなんらかの手を打つ必要があります。
稼働中のサービスを一気にクラウド移設または終了、みたいなことができれば話は早いのですが、そこには色々と複雑なビジネス上の事情というものが存在します。

簡単に言うと「クラウド移設という投資」をするには値せず、かといってシステムを停止するわけにはいかない判断がある、ということです。
事業としての成長性は見込めなくとも、保持する必要があるシステム群が残っていく、という言い方もできるかと思います。

こういった大人の事情に対応する手段として、設備集約という方法を取ります。

歯抜け状態になったサーバラックから必要なものを取り出し、同じように歯抜けになった別のサーバラックに入れて稼働させます。
使うラックは物理的に近いところにあったほうが回線などの設備の都合上簡素になりますので、なるべく近づけます。
多くのトラフィックを捌くための回線を細いものに付け替え、通信業者との契約を変更します。

過去同じデータセンター内に2つのフロアにまたがって設備を置いていたこともあり、とある段階でフロアの統合も行いました。

こういった集約作業を足掛け数年、過去5回ほどのフェーズにわけて実施をしてきました。

私とデータセンター

さて、一介のバックエンドエンジニアであった私ですが、現在プロダクトマネージャーという肩書で データセンター運営を含むシステム受託事業の事業責任者 をやっています。意味がわかりませんかね。私も自分が何を言っているかわからないです。

先程説明したようなデータセンター集約のプロジェクトを約半年〜1年単位の作業計画として立案し、「1000万の工事で来年1年のランニング費用が5000万お得になりますよ!」みたいなことを計算し、誰かに説明し、誰かに承認をとり実施にこぎつけます。

さすがにプロジェクト実施とその管理は他の方にお任せしていますが、保守事業そのものの収益と合わせた最終的な責任は私が持つ形になっています。

なぜそのようなことになってしまったのか?を紐解くのが今回の主題であります。前置きが長くて本当に申し訳ない。

オンプレ全盛期

バックエンドエンジニアである自分にとって、当時インフラは「誰かが要件に沿って用意してくれるもの」でありました。ミドルウェアレイヤーから上が自分の領域であったわけです。
当然、データセンターがどのように運用されているのか?や、ましてや費用についてなどは完全に意識の外にあったと言えます。

この頃はまだ、私とデータセンターの距離感はかなり遠いものであったと言えるでしょう。

クラウド移行期

先程説明したとおり、自分が担当としてクラウド移行(システムリプレイス)を行うことになるわけですが、この頃には自らがコードを書くよりもPM的な立ち位置が増えてきます。
それでも移設が決まったシステムをクラウド上へ構築するのが仕事なわけなので、データセンターのことはほとんど意識していません。
「マンションの空き部屋」がどうなるかなどは想像もしていませんでした。

この頃はまだ、私とデータセンターの距離感はかなり遠いものであったと言えるでしょう。

クラウド移行期その2

同様にシステムのリプレイスを担当している時期、なのですが立ち位置には変化が生まれ始めました。
「クラウド移行PJの責任者」として担当システムだけでなく、開発部門の管理職として横断的な移設計画を立てるようになってきます。各種の承認を取るための準備にも関わっていきます。
いくら掛かるのか?という概念が私の中で無視できなくなってくるのはこの頃からです。

データセンターが私をチラチラと見てくるようになりました。

管理職期

突然、インフラ部門のマネージャーを任されます。色々と理由はあったのですが今回は割愛します。
データセンターの運用や将来の計画に対して明確に責任が生まれました。もちろん実担当は部下となったメンバーがやってくれるわけですが、事情により2年のあいだで3回も担当者が変わっていくことも・・・割愛します。
毎月発生する保守費用などの発注承認など、データセンターに関わる費用を管理し始めたのもこの頃でした。

データセンターが着実に私に向かって歩みを進めはじめました。

そしてプロダクトマネージャーへ

2020年度、medibaは大きな組織改変を行いました。プロダクト/センターによるマトリクス組織の解説についてはこちらの記事をどうぞ。

組織の改変にあたり、件のデータセンター運営を含むシステム受託事業をどう扱うか?が議論になります。
大きな事業部を廃し、小さく判断の早い「プロダクト」という単位で事業の成長に責任を持つ組織。その中で古いシステムの受託事業は「成長性が見込めない」という点で異質です。

私は考えました。
・プロダクトマネージャーは事業を成長させる責任を持つ
・この事業は成長しない
・適切なコストダウンに向け、計画実施を行うのはたぶん私

・・・本職の事業責任者を立てず、私がやればいいのでは?が結論でした。

データセンター、今完全に私の隣にいます。

私とデータセンター

ということで、開発者としてシステムを運営保持していくうちに事業責任を負った男の話、いかがでしょうか。私以外に面白い人はいるのでしょうか。

個人的には「プロダクトマネージャー」という新たな分野での仕事、日々学ぶことが多く意外と楽しんでします。

エンジニアマネージャーとして、事業の考え方を知れたことはプラスであり、きっと今後に役立つことでしょう。このようなチャレンジをさせてくれる会社はありがたいなあ、と思っております。

medibaでの私のキャリアの変遷に、データセンターの歴史が密接に関わりなくては語れない関係になっています。

現在は20年度下期の集約作業を絶賛実施中。続いて21年度末にはまた大幅な縮小を見込んでいます。場合によってはすべての設備を解約できるかも・・・というところまで来ています。

クラウドの普及により、WEBサービス・システムのライフサイクルが早くなったこと、それに伴い技術の選択肢が増えたことは間違いありません。
「クラウド以前」を支えたオンプレミスのインフラ、過去に関わった人々に敬意を評しつつ終わりを迎えたいと思います。

2020年、いろいろありましたが2021年がみなさまにとって良い年になりますよう。


この記事が気に入ったらサポートをしてみませんか?