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

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

Transcript

1. グリー株式会社　シニアマネージャー　舟橋 弘兼 事業環境の変化に対応する インフラ組織 その取り組みと現状 グリー株式会社　マネージャー　黒木 誠士
2. 2
 自己紹介 舟橋 弘兼（ふなはし ひろかず） 2012年 入社 2017年 インフラ部マネージャ 2019年 インフラ部シニアマネージャ 所属 開発本部 インフラ部 サービスインストレーショングループ
3. 3
 自己紹介(黒木) 黒木 誠士（くろき まさし） 2020年 入社 2021年 インフラ部マネージャ 所属 開発本部 インフラ部 サービスインストレーショングループ
4. 4
 はじめに グリー株式会社は「インターネットを通じて、世界をより良くする。」というミッション を掲げ2004年に創業しました。 今もミッションは変わらずにいますが、時代の変化に伴い事業の変化や拡大を続 けてきました。 前半は、その変化の中でも変わらずに存続し続けてきたインフラ部の変遷を、事 業の変化と合わせてご説明していきます。 後半は、現在のインフラ部のエンジニアマネージャーの業務や取り組みについて ご紹介いたします。
5. 5
 アジェンダ • 組織変遷 • グリープラットフォーム(GPF)を中心とした組織 • AWS移行による組織 • 現在の組織 • 事業環境の変化にインフラ組織がどう対応しているか • 組織の変化に対応する • テクノロジーの変化に対応する
6. 6
 グリーは2004年に設立されてからこれまでの間、 グリーがなければできなかった、 この世に起こらなかったことを実現してきました そしてこれからも、自ら新しい歴史を刻んでいきます グリーの歩み 2022年 2020年 2018年 2016年 2014年 2012年 2010年 2008年 2006年 2004年 「GREE」誕生 モバイルSNS提供開始 モバイルSNS本格導入 世界初モバイルソーシャルゲーム公開 GREEプラットフォーム提供開始 GREEプラットフォームをグローバルで提供開始 ネイティブシフト初タイトルリリース 新規事業サービスリリース VRゲームリリース REALITYリリース メタバース事業 マンガ事業 Web3事業
7. 7
 グリーは2004年に設立されてからこれまでの間、 グリーがなければできなかった、 この世に起こらなかったことを実現してきました そしてこれからも、自ら新しい歴史を刻んでいきます グリーの歩み 2022年 2020年 2018年 2016年 2014年 2012年 2010年 2008年 2006年 2004年 「GREE」誕生 モバイルSNS提供開始 モバイルSNS本格導入 世界初モバイルソーシャルゲーム公開 GREEプラットフォーム提供開始 GREEプラットフォームをグローバルで提供開始 ネイティブシフト初タイトルリリース 新規事業サービスリリース VRゲームリリース REALITYリリース メタバース事業 マンガ事業 GREEプラットフォーム AWS移行 現在 Web3事業
8. GPF時代 グリー プラットフォーム LWF データセンター cascade yoyamagic MySQL memecached monitoring debian flare
9. GPF事業を第一にインフラとしてコミットする組織 • 技術要素 • オンプレ中心 • 内部での独自改修したOSSの利用 • 内製ツールの開発(https://github.com/gree) • 事業要素 • GPF事業が中心 9
 GPF時代
10. 運 用 GPF時代 ~この頃の組織~ デ ｜ タ セ ン タ ｜ インフラストラクチャ統括部 ネ ッ ト ワ ｜ ク サ | ビ ス リ ラ イ ア ビ リ テ ィ セ キ ュ リ テ ィ サ | バ マ ネ ジ メ ン ト ビ ッ グ デ |タ モ ニ タ リ ン グ 費 用 最 適 化 ハ ｜ ド ウ ェ ア 事 業 推 進
11. GPF時代 ~この頃の組織~ インフラストラクチャ統括部 データセンタ、サーバのコスト最適化 運 用 デ ｜ タ セ ン タ ｜ ネ ッ ト ワ ｜ ク サ | ビ ス リ ラ イ ア ビ リ テ ィ セ キ ュ リ テ ィ サ | バ マ ネ ジ メ ン ト ビ ッ グ デ |タ モ ニ タ リ ン グ 費 用 最 適 化 ハ ｜ ド ウ ェ ア 事 業 推 進
12. GPF時代 ~この頃の組織~ インフラストラクチャ統括部 オンプレ環境の円滑な運用 24/365で無停止で運用を継続する 運 用 デ ｜ タ セ ン タ ｜ ネ ッ ト ワ ｜ ク サ | ビ ス リ ラ イ ア ビ リ テ ィ セ キ ュ リ テ ィ サ | バ マ ネ ジ メ ン ト ビ ッ グ デ |タ モ ニ タ リ ン グ 費 用 最 適 化 ハ ｜ ド ウ ェ ア 事 業 推 進
13. GPF時代 ~この頃の組織~ インフラストラクチャ統括部 セキュリティを含めた管理/監視 大量のユーザ行動のビッグデータによる解析 運 用 デ ｜ タ セ ン タ ｜ ネ ッ ト ワ ｜ ク サ | ビ ス リ ラ イ ア ビ リ テ ィ セ キ ュ リ テ ィ サ | バ マ ネ ジ メ ン ト ビ ッ グ デ |タ モ ニ タ リ ン グ 費 用 最 適 化 ハ ｜ ド ウ ェ ア 事 業 推 進
14. GPF時代 ~この頃の組織~ インフラストラクチャ統括部 内製MW / VMの運用保守 自社独自のモニタリングシステムの構築 運 用 デ ｜ タ セ ン タ ｜ ネ ッ ト ワ ｜ ク サ | ビ ス リ ラ イ ア ビ リ テ ィ セ キ ュ リ テ ィ サ | バ マ ネ ジ メ ン ト ビ ッ グ デ |タ モ ニ タ リ ン グ 費 用 最 適 化 ハ ｜ ド ウ ェ ア 事 業 推 進
15. AWS移行時代 グリー プラットフォーム データ センター ubuntu monitoring ※ イメージ図 Managed Service 新規事業 ネイティブシフト LWF cascade yoyamagi c MySQL memecach ed flare apache
16. 16
 • 技術要素 • オンプレ中心からオンプレクラウドのハイブリッド運用 • 内部独自運用を極力減らしたOSSの利用 • インフラ部が独立した組織として組成 • 事業要素 • ネイティブゲームの新規事業の立ち上がり AWS移行時代 • 内製ツールの管理維持 • ハイブリッドクラウド環境の継続的な費用最適化
17. 17
 AWS移行時代 ~この頃の組織~ 開発本部 インフラサービス部 インフラサービス グループ インフラ導入 チーム データセンタ チーム ツール開発 チーム 費用最適化 チーム 運用 チーム エンジニアリング チーム 開発運用 グループ 情シス部 セキュリティ部 デザイン部 管理部 GPF部
18. 18
 AWS移行時代 ~この頃の組織~ 開発本部 インフラサービス部 インフラサービス グループ 開発運用 グループ 情シス部 セキュリティ部 デザイン部 管理部 GPF部 内製ツールの開発と、開発資産の運用保守 インフラ導入 チーム データセンタ チーム 費用最適化 チーム 運用 チーム エンジニアリング チーム ツール開発 チーム
19. AWS移行時代 ~この頃の組織~ 開発本部 インフラサービス部 インフラサービス グループ 開発運用 グループ 情シス部 セキュリティ部 デザイン部 管理部 GPF部 オンプレとクラウドのハイブリッド環境の継続的な費用最適化 インフラ導入 チーム データセンタ チーム ツール開発 チーム 費用最適化 チーム 運用 チーム エンジニアリング チーム
20. さらなる課題
21. GPF以外の複数の事業を支えるための課題
22. 事業部とのコミュニケーションコスト増
23. 23
 AWS移行時代 ~この頃の組織~ 開発本部 インフラサービス部 インフラサービス グループ インフラ導入 チーム データセンタ チーム ツール開発 チーム 費用最適化 チーム 運用 チーム エンジニアリング チーム 開発運用 グループ 情シス部 セキュリティ部 デザイン部 管理部 GPF部 事業部のオーダをインフラ設計に落とし込み、解決策を検討して実行までもっていく
24. コミュニケーションコストの削減 事業部 サービス導入 チーム 運用チーム エンジニアリン グチーム 事業オーダー プラン策定 作業依頼 可能な範囲は 自チームで対応 作業実施 手順整備 技術課題解決案 作成
25. 現在 グリー プラットフォーム データ センター monitoring ※ イメージ図 ManagedService
26. 26
 • 技術 • オンプレ + AWS + GCPのハイブリッド/マルチクラウド • SaaS、マネージドサービスの利用拡大 • 事業要素 • 子会社化、新規事業の立ち上がり • 事業拡大による社内開発案件の拡大 • 複雑化するハイブリッド/マルチクラウドの運用 • 調達部門としての計数管理（SaaSの利用拡大） 現在の組織
27. 運用チーム 開発グループ 運用改善チーム サービス開発チーム 企画チーム DC/Network チーム 部門戦略グループ 現在の組織 開発本部 インフラ部 運用グループ サービス導入グループ 業務改善チーム 導入1チーム 導入2チーム 導入3チーム PMチーム
28. 運用チーム 開発グループ 運用改善チーム サービス開発チーム 企画チーム DC/Network チーム 部門戦略グループ 現在の組織 開発本部 インフラ部 運用グループ サービス導入グループ 業務改善チーム 導入1チーム 導入2チーム 導入3チーム PMチーム 事業拡大による社内開発案件の対応
29. 運用チーム 開発グループ 運用改善チーム サービス開発チーム 企画チーム DC/Network チーム 部門戦略グループ 現在の組織 開発本部 インフラ部 運用グループ サービス導入グループ 業務改善チーム 導入1チーム 導入2チーム 導入3チーム PMチーム 複雑化するクラウド環境の運用保守対応 ハイブリッド、マルチクラウドによるネットワーク保守 長期運営プロダクトの MW ver UP
30. 運用チーム 開発グループ 運用改善チーム サービス開発チーム 企画チーム DC/Network チーム 部門戦略グループ 現在の組織 開発本部 インフラ部 運用グループ サービス導入グループ 業務改善チーム 導入1チーム 導入2チーム 導入3チーム PMチーム 調達部門としてのインフラの計数管理 SaaS利用など増加する外部との請求処理 研修や学習機会の創出
31. 事業のグループ会社化、新規事業立ち上がりによる さらなるコミュニケーションコスト増
32. 運用チーム 開発グループ 改善チーム サービス開発チーム 企画チーム DC/Network チーム 部門戦略グループ 現在の組織 開発本部 インフラ部 運用グループ サービス導入グループ 業務改善チーム 導入1チーム 導入2チーム 導入3チーム PMチーム より強固に事業部と連携した サービスのリリース支援
33. コミュニケーションコストの削減 運用チーム ユニット制 事業オーダー プラン策定 作業依頼 可能な範囲は 自チームで対応 作業実施 手順整備 事業オーダー 事業オーダー 導入1チーム 導入2チーム 導入3チーム 各子会社に特化し たチームを組成 技術課題解決案 作成
34. コミュニケーションコストの削減 運用チーム ユニット制 事業オーダー プラン策定 作業依頼 可能な範囲は 自チームで対応 作業実施 手順整備 事業オーダー 事業オーダー 導入1チーム 導入2チーム 導入3チーム 技術課題解決案 作成 新制度
35. 部門戦略 企画 35
 ユニット体制とは 業務改善 サービス導入1 サービス導入3 運用改善 PM RDBMS Frontend+Image Infra Platform Cloud サービス導入2 Datacenter/ Network サービス開発 運用 縦割り組織：チーム 横串組織 技術ユニット サービス導入 運用 開発 Infrastructure KVS Monitoring Dev Environment エンジニアは各チームに所属しつつ、 自分の得意分野となるユニットに所属 (1つ以 上)し、 得意分野の深度を増し、技術で事業に貢献す る構成
36. 36
 • 費用の集約 • 全社のインフラ関連の調達をすることでコスト最適化 • 技術の集約 • インフラ業務を集約することで、全社のインフラ環境を一定のレベル 以上担保する • グループ会社間でのインフラに関するナレッジの共有 • ユニット制による広く、深い技術スタックの醸成 • 技術をベースとした事業への貢献 大きなインフラ組織のメリット コミュニケーションコスト増などはあるも のの
37. 事業環境の変化に対応する取り組み 後半 37

38. 前半では組織としての対応をお伝えしました。 後半は複雑化するコミュニケーションと 変化の激しいテクノロジーに対する 現在の取り組みについてお話しします はじめに 後半でお伝えすること 38

39. いろいろと書いてはいますが、 実際の現場でできていること・できていないことは 個別にあると思います 社内の方は暖かく見守っていただけると幸いです󰢙 はじめに 後半でお伝えすること
40. 1. 組織の変化により発生する課題 • 「初対面から始まるプロジェクトの難しさ」 • 組織の変化によるコミュニケーションコストが課題となっている • 意外な「◦◦◦◦◦」が実は役に立つことも • インフラに限らずプロジェクトの円滑化に活用できる 2. テクノロジーの変化により発生する課題 • 「技術の変化はスピードが早く、新技術への対応難易度が高い」 • サーバはオンプレ+AWS+GCPになり、SaaSの利用も増加、インフラのカバー範囲 はさらに広がった 環境の変化による課題にどう対応しているか 後半でお伝えすること
41. 組織の変化に対応する 41

42. おさらい 運用チーム ユニット制 事業オーダー プラン策定 作業依頼 可能な範囲は 自チームで対応 作業実施 手順整備 事業オーダー 事業オーダー 導入1チーム 導入2チーム 導入3チーム 各子会社に特化し たチームを組成 技術課題解決案 作成
43. •課題：初対面から始まるプロジェクトの難しさ • 組織や事業体の変化に応じて、初対面のメンバーでプロジェクトを進める ことがよくある • 組織や事業体の変化に応じて、コミュニケーションコストが増大している 初対面から始まるプロジェクトの難しさ 組織の変化に対応する 43

44. コミュニケーションコストについて • 一般的には事業とインフラは一体化していることも多いが、前半の通 り現在のグリーはインフラが事業から独立している • チームや組織が分離しているとコミュニケーションコストは上がる 初対面から始まるプロジェクトの難しさ 組織の変化に対応する
45. 初対面から始まるプロジェクトの難しさ どのようにプロジェクトが始まるか • それなりに長い期間を共に走ることになるプロダクトとインフラが初対 面のところからプロジェクトが始まる • 慣れたメンバー同士だと人となりがわかっている・お互いのできること の期待値がある程度共有できているが、それがない 　→何が必要か 組織の変化に対応する キックオフ 設計 構築 負荷試験 リリース 運用
46. • 関係性を作る 組織の変化に対応する 46
 初対面から始まるプロジェクトの難しさ
47. • 関係性を作る • 期待値の共有 • お互いどんな事ができるかある程度把握できている • 何を求めているかある程度把握できている • コミュニケーションのとり方で迷わない • タスクをどのように管理しているか • お互いの担当領域はどこまでか なんだかんだ人間、知らない人と仕事をするよりは知ってる人と仕事をしたほうがやりやすい 組織の変化に対応する 47
 初対面から始まるプロジェクトの難しさ
48. 組織の変化に対応する 48
 • 初対面・基本ゼロベースで始まるプロジェクト • 関係性がない • 関係性を作って円滑にプロジェクトを進める • 関係性を作るためにはどうすればよいか • なにかしらの貢献をして、成果を出す →継続的な貢献のためにどうすればよいか？ 初対面から始まるプロジェクトの難しさ
49. • 意思決定のフレームワークを活用する： OODAループ 組織の変化に対応する 49
 初対面から始まるプロジェクトの難しさ
50. 組織の変化に対応する 50
 継続的な貢献のためにOODAループを回す 参考：変化の激しいWebの世界でコンスタントに局面局面で勝つ方法論「OODAループ」 https://speakerdeck.com/netmarkjp/bian-hua-falseji-siiwebfalseshi-jie-dekonsutantoniju-mian -ju-mian-desheng-tufang-fa-lun-oodarupu OODAループとはなにか Observe 観察 情報を取得 しにいく Orient 情勢判断 情報を解釈 する Decide 意思決定 行動を決定 する Action 行動 行動する/ 実行する Afterの 状況観察 Beforeの 状況観察
51. 組織の変化に対応する 51
 なぜOODAなのか • プロジェクトによってやるべきことは様々 • プロダクトからインフラへ何を求めているかが不確実 • コストはどのくらいを期待しているか • 開発期間中に何を求めているか • 負荷試験はどう行うか • リリース直後はどのような体制で臨むか • プロダクト側も最初から全て見通せているわけではない • 不確実性に対応するためにOODAを活用 初対面から始まるプロジェクトの難しさ
52. 組織の変化に対応する 52
 OODAの対応例 Observe 観察 情報を取得 しにいく Orient 情勢判断 情報を解釈 する Decide 意思決定 行動を決定 する Action 行動 行動する/ 実行する Afterの 状況観察 Beforeの 状況観察 EKS クラスタの k8s のバージョ ンが古そうだな 👀 updateするため の情報をお持ち でないかも🤔 選択肢とメリット・ デメリットをまと めて共有しよう 🧐 リリースタイミング で最適なverになる ように、ロードマップ を作成して提案した 💡
53. ◦◦◦◦◦を活用して関係性を作る 組織の変化に対応する 53
 • 観察とアクション、それに対するフィードバック • このサイクルが◦◦◦◦◦で強化できる
54. 定例MTGを活用して関係性を作る 組織の変化に対応する 54
 定例MTG もしかするとあんまり好きではない方もいらっしゃるかもしれませんが、使い方次第で。
55. • OODAのサイクルが定例MTGで強化できる • 知らない人同士だとコミュニケーションに障壁が出来がち • 習慣があればコミュニケーションが取れる • 定期的に必ず会って話す場を設定することで、観察からActionまで の機会が増える→課題解決の機会が増える 定例MTGを活用して関係性を作る 組織の変化に対応する 55
 もちろん、常に定例をやっていればいいというわけではなく。 OODAループが回り、関係性が出来てきたら頻度を調節するというのも必要
56. 定例MTGを活用して関係性を作る 組織の変化に対応する 56
 • OODAのサイクルが定例MTGで強化できる • OODAの繰り返しにより、インフラへどのような支援を頼めるの か/インフラからどう支援すべきか　という期待値のすり合わせが できる →関係性が構築できる • 関係性ができるとプロジェクトの進行がスムーズになる • プロジェクトがスムーズに進行していると、技術的なチャ レンジにも繋げやすくなる（後述）
57. • 組織変化への対応 • 組織の変化に起因したコミュニケーションコストへの対応として 関係性を作る必要がある • OODAループを活用して関係性を作る • 成果を積み重ねて関係性を作り、円滑にプロジェクトを進める 組織の変化に対応する　まとめ 57

58. テクノロジーの変化に対応する 58

59. • 課題：技術の変化はスピードが早く、新技術への対応難易度が高 い • サーバはオンプレ+AWS+GCPになり、SaaSの利用も増 加、インフラのカバー範囲はさらに広がった • 各プロダクトごとに検証や導入試験をやっていると効率が悪 い • 新しいものが次々と出てくる • 新しいものを取り入れるにもコストがかかる テクノロジーの変化に対応する 59

60. 部門戦略 企画 60
 業務改善 サービス導入1 サービス導入3 運用改善 PM RDBMS Frontend+Image Infra Platform Cloud サービス導入2 Datacenter/ Network サービス開発 運用 縦割り組織：チーム 横串組織 技術ユニット サービス導入 運用 開発 Infrastructure KVS Monitoring Dev Environment エンジニアは各チームに所属しつつ、 自分の得意分野となるユニットに所属 (1つ以 上)し、 得意分野の深度を増し、技術で事業に貢献す る構成 前提：ユニット体制
61. • 各技術Unitで知見を溜め、プロダクト支援に活かしている • オンプレからAWS、GCPと、インフラの基盤も変化を続けてきた 中、マネージドサービスの活用など、利用する技術も変化してきた →いくつか事例をご紹介します テクノロジーの変化に対応する、技術Unitのしくみ テクノロジーの変化に対応する 61

62. データベース分野の支援：RDBMS Unit • DBの運用支援ツール開発 • MySQLの運用ツール • Spannerのオートスケール・ウォームアップツール • MySQL 8.0 バージョンアップ支援 • クエリチューニング、パフォーマンスチューニング テクノロジーの変化に対応する 62
 テクノロジーの変化に対応する、技術Unitのしくみ
63. モニタリング分野の支援：Monitoring Unit • インフラの変化に合わせOSS/内製ツールを組み合わせ多様なプ ロダクト環境にObservability基盤を提供 • 既存ツールに不足があればカスタマイズ/内製ツール提供 • Spannerを新しく導入した際には必要なツール作成 • Spanner内部で集計しているstatisticsを Cloud Monitoringに記録 テクノロジーの変化に対応する 63
 テクノロジーの変化に対応する、技術Unitのしくみ
64. • Unitが先行して新しいサービスの技術を取り込み、プロダクトで 使いやすいように展開する テクノロジーの変化に対応する 64
 テクノロジーの変化に対応する、技術Unitのしくみ
65. • インフラチームでも新しい技術を取り入れやすくする テクノロジーの変化に対応する、チームでの取り組み テクノロジーの変化に対応する 65

66. • インフラチームでも新しい技術を取り入れやすくする • 目標設定の際に技術的なチャレンジを促進するようにしている テクノロジーの変化に対応する 66
 テクノロジーの変化に対応する、チームでの取り組み
67. • インフラチームでも新しい技術を取り入れやすくする • 目標設定の際に技術的なチャレンジを促進するようにしている • チャレンジにもコストがかかる テクノロジーの変化に対応する テクノロジーの変化に対応する、チームでの取り組み
68. • インフラチームでも新しい技術を取り入れやすくする • 目標設定の際に技術的なチャレンジを促進するようにしている • チャレンジにもコストがかかる • チャレンジにかかるコストは、コスト削減案を同時に盛り込むなど、ある 程度マネージャーの調整で解決していく • OODAのループによる信頼の積み重ねにより、プロダクトとインフラで技 術的なチャレンジを共有しやすい地盤を作る • 一定の導入コストをかけて新しい技術やサービスの導入で運用を楽にしておく と、次のチャレンジがしやすくなるといったループを回せる テクノロジーの変化に対応する テクノロジーの変化に対応する、チームでの取り組み
69. • プロダクトとインフラで技術的なチャレンジを繰り返し、より良いプロダクトを作れる 地盤を固めていく テクノロジーの変化に対応する テクノロジーの変化に対応する、チームでの取り組み インフラ技術 チャレンジ プロダクト技術 チャレンジ インフラ技術 チャレンジ プロダクト技術 チャレンジ いちばん大事なのは、プロダクトのために何ができるかを真剣に考え続けること、そしてそれを実行することだと思っていま す。 マネージャーレイヤとしては、メンバーへのこのマインドの伝達・共有が大事だなと考えています。（なかなかできていません が）
70. • 組織変遷 • グリープラットフォーム(GPF)を中心とした組織 • オンプレ環境を内製で支える組織 • AWS移行による組織 • 新規事業とクラウド活用の開始 • 現在の組織 • 事業の多角化、マルチクラウド環境 • 事業環境の変化にインフラ組織がどう対応しているか • 組織の変化に対応する • OODAループと定例MTGを活用して関係性を作る • テクノロジーの変化に対応する • 技術Unitでの知見の蓄積 • インフラチーム内での目標設定＋信頼関係 全体のまとめ
71. 採用強化中です！！ 一緒にインフラの課題解決にぶつかっていきたい方、ぜひご応募下さ い！！ • インフラエンジニア • https://hrmos.co/pages/gree/jobs/00030561 • インフラテクニカルPM • https://hrmos.co/pages/gree/jobs/00030562 We are hiring!! 71

72. • アンケートへのご協力をいただけますと幸いです！ ご清聴ありがとうございました！ 72