16
7

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

SupershipグループAdvent Calendar 2021

Day 25

会社の大規模データ基盤をクラウドへ移行することを意思決定した話

Last updated at Posted at 2021-12-25

この記事は、Supershipグループ Advent Calendar 2021 最終日の記事です。

#はじめに
Supership CTO の @noriakiutsu こと宇都宮です。
メリークリスマス!今年も最終日に投稿を担当します。
今回はDJ HASEBE のDJmix を聴きながら記事を書きました。

本年は弊社CTO が受け持つ役割の成果として、会社の大規模データ基盤をクラウドへ移行することを意思決定しました。
プラットフォームをパブリッククラウド間、オンプレミスからクラウド移行する話は従前よりインターネット上で見聞きする事ができます。
現場での実作業や発生した課題、問題点、どう解決したか?などがメイントピックになろうかと思います。
今回お話しする意思決定の話はトップダウンでこの決定を行うための様々なプロセスについて公表できる範囲でまとめてみました。

#背景
経営としてポートフォリオマネジメントを推進するに辺り、開発リソースを様々な意味で高度管理化せよという勅命を受けました。
今回の意思決定は昨年の背景から続くものであり、決定に至るまで一年以上の時間を要しました。

#事前設定
トップダウンで物事を動かす際、実際に動いてもらうメンバーに対し情報の透明性となぜ行うのか?に対する納得感の共有はとても重要です。
そのため以下のような取り組みを事前に設定しました。

  • 社内のタスクフォースプロジェクトとして全社に情報を公開
  • 公開情報は書記によりサマライズされているので、詳細内容をissueとしてredmineでチケット管理
  • redmine上のプロジェクトに閲覧アクセスを付与し原則SSOログイン可能な社員はトラッキング可能
  • 詳細内容は 5W1H 形式での記述を徹底
  • 内容の依存関係を親子、関連別に管理

#現状把握
社内で発生するワークロードは営む事業によりオンプレミス環境、その環境内で構築したプライベートクラウドであったりバプリッククラウド環境であったり様々な状況下で実行しています。
その中でもバプリッククラウド環境は以下の理由により既に把握ができている状態です。

  • サービスとして高度管理ができるようソフトウェアが振る舞ってくれる
  • 非機能要求もソフトウェアにある程度実装された上で提供されている
  • パブリッククラウドの Organizations 管理者、一人 CCoE としてこれまで推進してきた実績がある
  • 予算の予実管理を精度高く実施できる

以上の点からファクト収集としてオンプレミス環境を主なワークロードとして活用する関係者に対し
現場ヒアリングと管理できている計数の把握を実施しました。
関係者はインフラを支える技術チームのみならず、事業側計数管理担当、経営側計数管理担当、固定資産計上業務などの観点から財務・経理部門など多岐に渡ります。
またデータセンター事業者の皆様にも顔合わせを実施させて頂き、昨年末約20年ぶりにデータセンターまで足を運び視察しました。

余談となりますが国内の事業者トップクラスと呼べる圧巻の設備は自然空冷で設備維持の設計をしているセンターであっても、真冬なのにTシャツ一枚で過ごせる程排熱が凄まじい環境でした。
幼い子を持つ親としては子が長く生存可能な環境を提供する義務があるので、地球の環境変動について一考する機会を与えられた気がします。

#確認

時間をかけた上でファクトを収集し、オンプレミス環境に対する課題抽出とその対応について関係各所に確認しました。

  • キードライバー分析はできているか
    既に存在する基盤を用いて施策を行うにあたり、どのワークロードがボトルネックとなるか(=改善ポイント)ビジネスを推進する側と開発と運用を推進する側の間での情報共有に対する意識

  • 非機能要求をどこまで満たしているか
    可用性、性能・拡張性、運用・保守性、移行性、セキュリティ、システム環境・エコロジーへの要求のうち特にセキュリティに対する意識

  • 財務経理上の懸念
    固定資産計上対象となるサーバやネットワーク機器の減価償却と残存簿価、リースするハウジングラックの契約時期など主にタイムライン管理

  • 資材調達などロジスティクスと取り扱う人材確保上の懸念
    昨年時点で既に全世界的な半導体不足による納期遅延が発生
    該当人材の募集要項に対してどの程度応募があり採用に至っているか、また社内の人材育成の状況

#決定事項
以下の観点から会社の大規模データ基盤をクラウドへ移行することをまずは自分の中で決めました。

  • ITライフサイクルを適切に回すこと
    今回対象とした大規模データ基盤は数PBのデータ容量を保持する基盤です。データを保持する事は直接的な売上に貢献しないのでコストを抑制する事を求められます。
    その要件として地代などホスティングするのにより安い場所のデータセンターを利用し、1,000台に満たない台数のサーバに分散配置していますが、そのうちの2/3は来年減価償却が完了し除却を予定していました。
    データを分散配置しているとはいえ通常業務ラインを侵害せずに数百台もの物理サーバのリプレース作業にかける工数と時間を計画するには時間が足りません。
    ブルーグリーンデプロイメントを実現するための余剰も物理的な空間、サーバ等予算都合上用意できない事からワークロードをクラウドに移行する方が望ましいと考えました。

  • 非機能要求を満たすこと
    過去経緯から対象のデータ基盤に対する非機能要求はほぼ満たされていません。
    これはこれまでのマネジメントの怠慢です。
    その結果現在何が起きているかというと深刻なデータガバナンスの欠落となって関係者を悩ませています。
    この統制機能を現行の環境にゼロから実装する事は専門知識を持った人材、プログラミングスキルを持った人材を確保する面からとても難易度が高いです。
    クラウドを利用するとソフトウェアとして提供される上様々なセキュリティ規格にも準拠しています。

  • CapExからOpExへシフト可能な資産を移行し固定資産管理上の認知負荷を下げること
    資産の検収作業、棚卸しなど各拠点まで出向き資産管理することはメンタル・フィジカルの両面で大きな負荷が現場のエンジニアのみならず管理部門にも大きくのしかかる作業です。
    会社の計上方法にもよりますが、経営上のバランスを勘案しながら流動資産化しうる資産を様々な制約から解放し ”Two-way door” を実現する事はAWSの成功事例を見ても明らかです。

  • ビジネス環境の大変動に迅速に対応できること
    コンピューティングリソースの調達、売上に貢献する生産量の拡大、ビジネスの利益率などの要素から2019年までであれば規模の経済の原則、最小効率規模(MES)に乗っかったスケール戦略を我々も採用できました。
    コロナ禍以降リソースの調達面とプラントとは違い稼働率は100%近いにも関わらず売上に貢献しない生産量の増加により、規模の経済が説明する『ビッグスケールする事で生産量を増やし単位コストが下がるので利益が向上する』という原則が適用できなくなりました。
    AmazonやGoogleのビッグスケーラーがコロナなど関係なく利益を拡大できるのは何故か?
    彼らが設備投資すればするほど一般消費者のclick に依存する不確定な事業(ECや広告、それでも莫大な利益を上げていますが)をカバーする形でパブリッククラウドベンダー事業を営み、直接コンピューティングリソースを販売する事ができる点が挙げられると思います。
    ですのでビジネス観点でも*”Two-way door”* を実現する事が重要と考えました。

  • 事業を継続するための人材獲得戦略
    大規模データ基盤に関わる人材を現在募集中ではありますが、実に5年間も新規入社された方はいません。
    会社からオンプレミス環境による大規模データ基盤の運用ノウハウが失くなる事を危惧する声が以前はありました。
    環境変化に伴い適切に運用し続ける事が知見として会社に蓄積されていかなければならない上で現状を維持する事は知見でもなんでもありません。
    特定のミドルウェアに対する知見、知識を持たれたエンジニアの新規採用が針の穴を通すより現在困難な事は5年間採用の実績がないというファクトから明らかですので現在の採用市場に合わせた人材獲得戦略も必要となります。
    また社内のエコサイクル観点から既にデータ基盤をクラウドで運用している実績があるので技術情報の共有を容易にするという目的もありました。

  • 棚卸し
    システムをリファクタリングする、事業をピボットする際など共通として行える事があります。
    それは“棚卸し”です。
    特にシステムの使用年数が長いほど、別のシステム移行時に棚卸しによる効果が生まれます。
    保持しているデータは移行しても本当に必要なのか?
    大量のユーザアカウントも離職者のアカウントがないか?
    このワークロードジョブは既に終わった業務のジョブではないか?
    など管理がおざなりになっていたり、通例として引き継いだものが実際は無駄だったりという事を炙り出す絶好の機会です。

#調整
自分の中でクラウドに移行する事を決めてから各パブリッククラウドベンダー様と会話を開始しました。
同時に影響を受ける人達一人一人に対し個別に情報を共有し、移行するために必要なタスクの洗い出し、PoCなど実働をお願いする事ができました。
半年程時間をかけクラウド移行への確実性を数字で表現可能なようになってから
財務経理部門や各ステークホルダーに対し上程前に情報を共有し、懸念点があれば伝えてもらい
より確度を上げ役員会議での上程まで根回しを行いました。

#上程
事前の根回しや中期計画シミュレーションを具体的な数字で表しながらなぜ今回このような提案に至ったか
経営会議、取締役会と二度の上程を行いましたが両会議体共に一発で無事承認となりました。

#おわりに
公開可能な情報を元に投稿したのでとても抽象的な内容となり恐縮ですがいかがでしたでしょうか?
今回は意思決定を行った話ですが、次回事の顛末をキチンと精査してお伝えできればと思います。

"With great power comes great responsibility." ~大いなる力には大いなる責任が伴う~

トップダウンで決定した事柄がその後検証され評価される事は往々にして少ないので、その点は責任をもって確認を行います。(来年私がこのテーマを投稿していなければ責任を取ったとお察しくださいw)
また現場でも当然現状維持が健全な状態と思っていないという声を今回のみならず過去から多数見聞きしていました。
課題を感じている現場の声を的確に抽出し、解決に向けて迅速に動かないマネジメント、どのようなプロセスを経てこのような意思決定を行うのか?という事を現場に伝えない(自ら動いてないので経験として伝えられない)マネジメントにこそ問題があると感じたので今回実践した事を明文化した次第です。
すべては健全なエンジニアリングを実践したいだけなのです。

激しいVUCAな時代を生き抜く為に、時としてこのようなトップダウンによる決断が成される場合もありますが
日頃から俯瞰して物事を観察、判断する行動を鍛え、ボトムアップによる決断がより多く成される事を望んでいます。

#宣伝
Supershipグループでは一緒に働いてくださる方を切実に望んでおります。
本記事を読んでご興味がある、いつかこの会社でCTOをやってやってもいいぞという方がおられましたら
以下リンクより是非弊社採用情報をご一読ください。

Supershipグループ 採用サイト

#おまけ
今年無事。
今年も ILL-BOSSTINO のこの言葉を捧げます。
皆さま良いお年をお迎えください。

16
7
1

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
16
7

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?