Upgrade to PRO for Only $50/Year—Limited-Time Offer! 🔥

事業環境の変化に対応するインフラ組織 その取り組みと現状

gree_tech
October 25, 2022

 事業環境の変化に対応するインフラ組織 その取り組みと現状

GREE Tech Conference 2022で発表された資料です。
https://techcon.gree.jp/2022/session/TrackA-6

gree_tech

October 25, 2022
Tweet

More Decks by gree_tech

Other Decks in Technology

Transcript

  1. 2
 自己紹介 舟橋 弘兼(ふなはし ひろかず) 2012年 入社 2017年 インフラ部マネージャ 2019年

    インフラ部シニアマネージャ 所属 開発本部 インフラ部 サービスインストレーショングループ
  2. 5
 アジェンダ • 組織変遷 • グリープラットフォーム(GPF)を中心とした組織 • AWS移行による組織 • 現在の組織

    • 事業環境の変化にインフラ組織がどう対応しているか • 組織の変化に対応する • テクノロジーの変化に対応する
  3. 6
 グリーは2004年に設立されてからこれまでの間、 グリーがなければできなかった、 この世に起こらなかったことを実現してきました そしてこれからも、自ら新しい歴史を刻んでいきます グリーの歩み 2022年 2020年 2018年 2016年

    2014年 2012年 2010年 2008年 2006年 2004年 「GREE」誕生 モバイルSNS提供開始 モバイルSNS本格導入 世界初モバイルソーシャルゲーム公開 GREEプラットフォーム提供開始 GREEプラットフォームをグローバルで提供開始 ネイティブシフト初タイトルリリース 新規事業サービスリリース VRゲームリリース REALITYリリース メタバース事業 マンガ事業 Web3事業
  4. 7
 グリーは2004年に設立されてからこれまでの間、 グリーがなければできなかった、 この世に起こらなかったことを実現してきました そしてこれからも、自ら新しい歴史を刻んでいきます グリーの歩み 2022年 2020年 2018年 2016年

    2014年 2012年 2010年 2008年 2006年 2004年 「GREE」誕生 モバイルSNS提供開始 モバイルSNS本格導入 世界初モバイルソーシャルゲーム公開 GREEプラットフォーム提供開始 GREEプラットフォームをグローバルで提供開始 ネイティブシフト初タイトルリリース 新規事業サービスリリース VRゲームリリース REALITYリリース メタバース事業 マンガ事業 GREEプラットフォーム AWS移行 現在 Web3事業
  5. 運 用 GPF時代 ~この頃の組織~ デ | タ セ ン タ

    | インフラストラクチャ統括部 ネ ッ ト ワ | ク サ | ビ ス リ ラ イ ア ビ リ テ ィ セ キ ュ リ テ ィ サ | バ マ ネ ジ メ ン ト ビ ッ グ デ |タ モ ニ タ リ ン グ 費 用 最 適 化 ハ | ド ウ ェ ア 事 業 推 進
  6. GPF時代 ~この頃の組織~ インフラストラクチャ統括部 データセンタ、サーバのコスト最適化 運 用 デ | タ セ

    ン タ | ネ ッ ト ワ | ク サ | ビ ス リ ラ イ ア ビ リ テ ィ セ キ ュ リ テ ィ サ | バ マ ネ ジ メ ン ト ビ ッ グ デ |タ モ ニ タ リ ン グ 費 用 最 適 化 ハ | ド ウ ェ ア 事 業 推 進
  7. GPF時代 ~この頃の組織~ インフラストラクチャ統括部 オンプレ環境の円滑な運用 24/365で無停止で運用を継続する 運 用 デ | タ

    セ ン タ | ネ ッ ト ワ | ク サ | ビ ス リ ラ イ ア ビ リ テ ィ セ キ ュ リ テ ィ サ | バ マ ネ ジ メ ン ト ビ ッ グ デ |タ モ ニ タ リ ン グ 費 用 最 適 化 ハ | ド ウ ェ ア 事 業 推 進
  8. GPF時代 ~この頃の組織~ インフラストラクチャ統括部 セキュリティを含めた管理/監視 大量のユーザ行動のビッグデータによる解析 運 用 デ | タ

    セ ン タ | ネ ッ ト ワ | ク サ | ビ ス リ ラ イ ア ビ リ テ ィ セ キ ュ リ テ ィ サ | バ マ ネ ジ メ ン ト ビ ッ グ デ |タ モ ニ タ リ ン グ 費 用 最 適 化 ハ | ド ウ ェ ア 事 業 推 進
  9. GPF時代 ~この頃の組織~ インフラストラクチャ統括部 内製MW / VMの運用保守 自社独自のモニタリングシステムの構築 運 用 デ

    | タ セ ン タ | ネ ッ ト ワ | ク サ | ビ ス リ ラ イ ア ビ リ テ ィ セ キ ュ リ テ ィ サ | バ マ ネ ジ メ ン ト ビ ッ グ デ |タ モ ニ タ リ ン グ 費 用 最 適 化 ハ | ド ウ ェ ア 事 業 推 進
  10. AWS移行時代 グリー プラットフォーム データ センター ubuntu monitoring ※ イメージ図 Managed

    Service 新規事業 ネイティブシフト LWF cascade yoyamagi c MySQL memecach ed flare apache
  11. 16
 • 技術要素 • オンプレ中心からオンプレクラウドのハイブリッド運用 • 内部独自運用を極力減らしたOSSの利用 • インフラ部が独立した組織として組成 •

    事業要素 • ネイティブゲームの新規事業の立ち上がり AWS移行時代 • 内製ツールの管理維持 • ハイブリッドクラウド環境の継続的な費用最適化
  12. 17
 AWS移行時代 ~この頃の組織~ 開発本部 インフラサービス部 インフラサービス グループ インフラ導入 チーム データセンタ

    チーム ツール開発 チーム 費用最適化 チーム 運用 チーム エンジニアリング チーム 開発運用 グループ 情シス部 セキュリティ部 デザイン部 管理部 GPF部
  13. 18
 AWS移行時代 ~この頃の組織~ 開発本部 インフラサービス部 インフラサービス グループ 開発運用 グループ 情シス部

    セキュリティ部 デザイン部 管理部 GPF部 内製ツールの開発と、開発資産の運用保守 インフラ導入 チーム データセンタ チーム 費用最適化 チーム 運用 チーム エンジニアリング チーム ツール開発 チーム
  14. AWS移行時代 ~この頃の組織~ 開発本部 インフラサービス部 インフラサービス グループ 開発運用 グループ 情シス部 セキュリティ部

    デザイン部 管理部 GPF部 オンプレとクラウドのハイブリッド環境の継続的な費用最適化 インフラ導入 チーム データセンタ チーム ツール開発 チーム 費用最適化 チーム 運用 チーム エンジニアリング チーム
  15. 23
 AWS移行時代 ~この頃の組織~ 開発本部 インフラサービス部 インフラサービス グループ インフラ導入 チーム データセンタ

    チーム ツール開発 チーム 費用最適化 チーム 運用 チーム エンジニアリング チーム 開発運用 グループ 情シス部 セキュリティ部 デザイン部 管理部 GPF部 事業部のオーダをインフラ設計に落とし込み、解決策を検討して実行までもっていく
  16. 26
 • 技術 • オンプレ + AWS + GCPのハイブリッド/マルチクラウド •

    SaaS、マネージドサービスの利用拡大 • 事業要素 • 子会社化、新規事業の立ち上がり • 事業拡大による社内開発案件の拡大 • 複雑化するハイブリッド/マルチクラウドの運用 • 調達部門としての計数管理(SaaSの利用拡大) 現在の組織
  17. 運用チーム 開発グループ 運用改善チーム サービス開発チーム 企画チーム DC/Network チーム 部門戦略グループ 現在の組織 開発本部

    インフラ部 運用グループ サービス導入グループ 業務改善チーム 導入1チーム 導入2チーム 導入3チーム PMチーム
  18. 運用チーム 開発グループ 運用改善チーム サービス開発チーム 企画チーム DC/Network チーム 部門戦略グループ 現在の組織 開発本部

    インフラ部 運用グループ サービス導入グループ 業務改善チーム 導入1チーム 導入2チーム 導入3チーム PMチーム 事業拡大による社内開発案件の対応
  19. 運用チーム 開発グループ 運用改善チーム サービス開発チーム 企画チーム DC/Network チーム 部門戦略グループ 現在の組織 開発本部

    インフラ部 運用グループ サービス導入グループ 業務改善チーム 導入1チーム 導入2チーム 導入3チーム PMチーム 複雑化するクラウド環境の運用保守対応 ハイブリッド、マルチクラウドによるネットワーク保守 長期運営プロダクトの MW ver UP
  20. 運用チーム 開発グループ 運用改善チーム サービス開発チーム 企画チーム DC/Network チーム 部門戦略グループ 現在の組織 開発本部

    インフラ部 運用グループ サービス導入グループ 業務改善チーム 導入1チーム 導入2チーム 導入3チーム PMチーム 調達部門としてのインフラの計数管理 SaaS利用など増加する外部との請求処理 研修や学習機会の創出
  21. 運用チーム 開発グループ 改善チーム サービス開発チーム 企画チーム DC/Network チーム 部門戦略グループ 現在の組織 開発本部

    インフラ部 運用グループ サービス導入グループ 業務改善チーム 導入1チーム 導入2チーム 導入3チーム PMチーム より強固に事業部と連携した サービスのリリース支援
  22. コミュニケーションコストの削減 運用チーム ユニット制 事業オーダー プラン策定 作業依頼 可能な範囲は 自チームで対応 作業実施 手順整備

    事業オーダー 事業オーダー 導入1チーム 導入2チーム 導入3チーム 各子会社に特化し たチームを組成 技術課題解決案 作成
  23. コミュニケーションコストの削減 運用チーム ユニット制 事業オーダー プラン策定 作業依頼 可能な範囲は 自チームで対応 作業実施 手順整備

    事業オーダー 事業オーダー 導入1チーム 導入2チーム 導入3チーム 技術課題解決案 作成 新制度
  24. 部門戦略 企画 35
 ユニット体制とは 業務改善 サービス導入1 サービス導入3 運用改善 PM RDBMS

    Frontend+Image Infra Platform Cloud サービス導入2 Datacenter/ Network サービス開発 運用 縦割り組織:チーム 横串組織 技術ユニット サービス導入 運用 開発 Infrastructure KVS Monitoring Dev Environment エンジニアは各チームに所属しつつ、 自分の得意分野となるユニットに所属 (1つ以 上)し、 得意分野の深度を増し、技術で事業に貢献す る構成
  25. 36
 • 費用の集約 • 全社のインフラ関連の調達をすることでコスト最適化 • 技術の集約 • インフラ業務を集約することで、全社のインフラ環境を一定のレベル 以上担保する

    • グループ会社間でのインフラに関するナレッジの共有 • ユニット制による広く、深い技術スタックの醸成 • 技術をベースとした事業への貢献 大きなインフラ組織のメリット コミュニケーションコスト増などはあるも のの
  26. 1. 組織の変化により発生する課題 • 「初対面から始まるプロジェクトの難しさ」 • 組織の変化によるコミュニケーションコストが課題となっている • 意外な「◦◦◦◦◦」が実は役に立つことも • インフラに限らずプロジェクトの円滑化に活用できる

    2. テクノロジーの変化により発生する課題 • 「技術の変化はスピードが早く、新技術への対応難易度が高い」 • サーバはオンプレ+AWS+GCPになり、SaaSの利用も増加、インフラのカバー範囲 はさらに広がった 環境の変化による課題にどう対応しているか 後半でお伝えすること
  27. おさらい 運用チーム ユニット制 事業オーダー プラン策定 作業依頼 可能な範囲は 自チームで対応 作業実施 手順整備

    事業オーダー 事業オーダー 導入1チーム 導入2チーム 導入3チーム 各子会社に特化し たチームを組成 技術課題解決案 作成
  28. • 関係性を作る • 期待値の共有 • お互いどんな事ができるかある程度把握できている • 何を求めているかある程度把握できている • コミュニケーションのとり方で迷わない

    • タスクをどのように管理しているか • お互いの担当領域はどこまでか なんだかんだ人間、知らない人と仕事をするよりは知ってる人と仕事をしたほうがやりやすい 組織の変化に対応する 47
 初対面から始まるプロジェクトの難しさ
  29. 組織の変化に対応する 48
 • 初対面・基本ゼロベースで始まるプロジェクト • 関係性がない • 関係性を作って円滑にプロジェクトを進める • 関係性を作るためにはどうすればよいか

    • なにかしらの貢献をして、成果を出す →継続的な貢献のためにどうすればよいか? 初対面から始まるプロジェクトの難しさ
  30. 組織の変化に対応する 51
 なぜOODAなのか • プロジェクトによってやるべきことは様々 • プロダクトからインフラへ何を求めているかが不確実 • コストはどのくらいを期待しているか •

    開発期間中に何を求めているか • 負荷試験はどう行うか • リリース直後はどのような体制で臨むか • プロダクト側も最初から全て見通せているわけではない • 不確実性に対応するためにOODAを活用 初対面から始まるプロジェクトの難しさ
  31. 組織の変化に対応する 52
 OODAの対応例 Observe 観察 情報を取得 しにいく Orient 情勢判断 情報を解釈

    する Decide 意思決定 行動を決定 する Action 行動 行動する/ 実行する Afterの 状況観察 Beforeの 状況観察 EKS クラスタの k8s のバージョ ンが古そうだな 👀 updateするため の情報をお持ち でないかも🤔 選択肢とメリット・ デメリットをまと めて共有しよう 🧐 リリースタイミング で最適なverになる ように、ロードマップ を作成して提案した 💡
  32. 部門戦略 企画 60
 業務改善 サービス導入1 サービス導入3 運用改善 PM RDBMS Frontend+Image

    Infra Platform Cloud サービス導入2 Datacenter/ Network サービス開発 運用 縦割り組織:チーム 横串組織 技術ユニット サービス導入 運用 開発 Infrastructure KVS Monitoring Dev Environment エンジニアは各チームに所属しつつ、 自分の得意分野となるユニットに所属 (1つ以 上)し、 得意分野の深度を増し、技術で事業に貢献す る構成 前提:ユニット体制
  33. データベース分野の支援:RDBMS Unit • DBの運用支援ツール開発 • MySQLの運用ツール • Spannerのオートスケール・ウォームアップツール • MySQL

    8.0 バージョンアップ支援 • クエリチューニング、パフォーマンスチューニング テクノロジーの変化に対応する 62
 テクノロジーの変化に対応する、技術Unitのしくみ
  34. • インフラチームでも新しい技術を取り入れやすくする • 目標設定の際に技術的なチャレンジを促進するようにしている • チャレンジにもコストがかかる • チャレンジにかかるコストは、コスト削減案を同時に盛り込むなど、ある 程度マネージャーの調整で解決していく •

    OODAのループによる信頼の積み重ねにより、プロダクトとインフラで技 術的なチャレンジを共有しやすい地盤を作る • 一定の導入コストをかけて新しい技術やサービスの導入で運用を楽にしておく と、次のチャレンジがしやすくなるといったループを回せる テクノロジーの変化に対応する テクノロジーの変化に対応する、チームでの取り組み
  35. • プロダクトとインフラで技術的なチャレンジを繰り返し、より良いプロダクトを作れる 地盤を固めていく テクノロジーの変化に対応する テクノロジーの変化に対応する、チームでの取り組み インフラ技術 チャレンジ プロダクト技術 チャレンジ インフラ技術

    チャレンジ プロダクト技術 チャレンジ いちばん大事なのは、プロダクトのために何ができるかを真剣に考え続けること、そしてそれを実行することだと思っていま す。 マネージャーレイヤとしては、メンバーへのこのマインドの伝達・共有が大事だなと考えています。(なかなかできていません が)
  36. • 組織変遷 • グリープラットフォーム(GPF)を中心とした組織 • オンプレ環境を内製で支える組織 • AWS移行による組織 • 新規事業とクラウド活用の開始

    • 現在の組織 • 事業の多角化、マルチクラウド環境 • 事業環境の変化にインフラ組織がどう対応しているか • 組織の変化に対応する • OODAループと定例MTGを活用して関係性を作る • テクノロジーの変化に対応する • 技術Unitでの知見の蓄積 • インフラチーム内での目標設定+信頼関係 全体のまとめ