DeNAのインフラ戦略 〜クラウドジャーニーの舞台裏〜 [DeNA TechCon 2019]
•Als PPTX, PDF herunterladen•
3 gefällt mir•24,521 views
DeNAでは、メインのシステム基盤をオンプレミスからpublicクラウドへと全面移行する決定をしました。創業時より数々のサービスをオンプレミスで提供し、高品質・低コストの大規模なインフラをつくりあげてきたDeNAですが、なぜ今回クラウドへの舵を切ったのか。 本セッションでは、その背景には何があったのか、どのように低コストを維持する目処を立て、移行の決断をしたのかをお話します。オートスケールやスポットインスタンスの利用の工夫など、オンプレミスからクラウドへのシフトを考えている方だけでなく、現在クラウドを利用されている方にもお楽しみいただけるように話します。
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie DeNAのインフラ戦略 〜クラウドジャーニーの舞台裏〜 [DeNA TechCon 2019]
Ähnlich wie DeNAのインフラ戦略 〜クラウドジャーニーの舞台裏〜 [DeNA TechCon 2019] (20)
Mehr von DeNA
Mehr von DeNA (20)
DeNAのインフラ戦略 〜クラウドジャーニーの舞台裏〜 [DeNA TechCon 2019]
- 4. #denatechcon 自己紹介：金子 俊一（Shunichi Kaneko） • 現職 システム本部 IT基盤部 部長 • IT基盤部は，全グループ横断で全てのシステム基盤を管理 • DeNAグループのインフラ全体戦略を立案/推進する役割 • 職歴 • 2003年 開発エンジニアとしてキャリアスタート • 2009年 開発エンジニアとしてDeNA入社 • 2011年 インフラエンジニアに転身 • 2013年 インフラ部門マネージャ就任 • 2018年 現職 • 開発エンジニア50%，インフラエンジニア50%
- 5. #denatechcon DeNAのインフラ戦略 • 背景 • なぜDeNAは戦略を転換するのか • 検討 • オンプレミスからマルチクラウドへ • 調整 • 全社方針とプロジェクト化 • 実行 • 安定運用とコストコントロールの両立
- 7. #denatechcon DeNAのシステム基盤の状況 1/3 • 適材適所 • メインのシステム基盤はオンプレミス • 圧倒的に安いコスト • 明確な理由がある場合はpublicクラウドを選択 • 2013年〜利用開始，2015年〜利用急増 • メインはAWSとGCP，現在はオンプレミスと同規模 • オンプレミス型privateクラウドへの挑戦（OpenStack＋Ceph） • オンプレミスのノウハウを活かして柔軟性もアップ • 高難度な課題が散発，基盤整備に要する工数の増加 • トップレベルのシステム品質 • 圧倒的な低コスト
- 8. #denatechcon DeNAのシステム基盤の状況 2/3 • 適材適所 • トップレベルのシステム品質 • 高トラフィックと大規模データの取り扱いノウハウ • 数十万リクエスト/秒，PBクラスのデータ • 既存システムを安定して動かし “続ける” • 24時間365日 • インフラ起因のエラーは1件も放置しない • 新規システムの短期構築と安定リリース • 初速が数千万ユーザでもサーバダウンゼロ • リリースまでの全行程が3ヶ月 • 圧倒的な低コスト
- 9. #denatechcon DeNAのシステム基盤の状況 3/3 • 適材適所 • トップレベルのシステム品質 • 圧倒的な低コスト • 3,000台規模のオンプレミス • 事業規模からすると相当少ない台数 • 「1円でも安く」のベンチャーマインド • 固定スペックのサーバを大量購入 • 調達価格の圧縮と流動性の確保⇒全体台数削減 • サーバリソースをフル活用 • KVM，マルチインスタンス構成，相乗り構成 • 徹底したチューニング
- 10. #denatechcon DeNAのシステム基盤を取り巻く環境 • 事業サービスの多様化 • ゲーム＆エンタメ • ソーシャルLIVE • ヘルスケア • オートモーティブ • スポーツ • 事業サービス以外の多様化 • セキュリティ（脆弱性, 監査, 各種認証） • コンプライアンス（改正個人情報保護法，EU GDPR） • 災害対策（Disaster Recovery） • システム基盤/技術要素の多様化 • ベアメタルと仮想化環境とprivateクラウド環境 • 複数のpublicクラウド環境
- 11. #denatechcon DeNAのシステム基盤の課題 • オンプレミス環境の老朽化 • 前回の大規模サーバリプレイスは6年前 • サーバ故障率増加で運用工数が増加 • トータルシステムコストの増加 • publicクラウドの利用拡大に起因 • コストコントロールが不十分 • レガシー化による事業リスクの増加 • Mobageもサービス開始から13年 • 事業展開スピードを支える敏捷性と柔軟性 • 多様化による工数の逼迫 • システム基盤管理の難化と工数の分散 • セキュリティ対応/対策の工数も増加 部門作業時間比率
- 13. #denatechcon 次期システム基盤の要件 • システム基盤の課題の解決 • オンプレミス環境の老朽化 • トータルシステムコストの増加 • レガシー化による事業リスクの増加 • 多様化による工数の逼迫 • 既存の要件も満たし続ける • トップレベルのシステム品質の維持 • 圧倒的な低コストの維持と更なる削減 • 多様化する環境と事業展開スピードにも対応 • リソース制約 • 限られた工数と期間で実現 • 「工数削減⇒改善⇒更に工数削減」というスパイラルを回したい
- 14. #denatechcon オンプレミスサーバの大規模リプレイス？ • Meet • オンプレミスの老朽化は一旦解消（ただし数年後に要リプレイス） • 最新サーバへの集約で，オンプレミスのコスト削減が可能 • システム品質は確実に高水準を維持可能 • リプレイスはごく短期間，必要最小限の工数で実現可能 • Not meet • publicクラウドとの併用は不可避，工数逼迫は変わらず • publicクラウドのコスト削減には繋がらない • 複製で環境移行できてしまうので，技術負債は手付かず • 多様化する環境と事業展開スピードに応え続ける工数とコスト • フルでDRサイトを構築するとコストは2倍
- 15. #denatechcon オンプレミス型privateクラウドへの集約？ • Meet • オンプレミスの老朽化は一旦解消（ただし数年後に要リプレイス） • 最新サーバへの集約で，オンプレミスのコスト削減が可能 • リプレイスはごく短期間，必要最小限の工数で実現可能 • オンプレミス環境の運用工数削減が可能（live migrationの活用など） • Not meet • システム品質の高水準維持の難しさ • publicクラウドとの併用は不可避，工数逼迫は変わらず • publicクラウドのコスト削減には繋がらない • 複製で環境移行できてしまうので，技術負債は手付かず • 多様化する環境と事業展開スピードに応え続ける工数とコスト • フルでDRサイトを構築するとコストは2倍
- 16. #denatechcon publicクラウドへの集約？ • Meet • オンプレミスの老朽化が解消 • システム基盤刷新による技術負債解消への期待 • システム投資と工数の集中によるパフォーマンス最大化 • 多様化する環境と事業展開スピードに応え続ける敏捷性と柔軟性 • 常に最新スペックのリソース調達が圧倒的に容易 • システム品質は確実に高水準を維持可能（2015年〜の運用ノウハウ） • 事業継続リスクの大幅な軽減 • DRサイトが格安で構築可能 • セキュリティ，コンプライアンスのための豊富なソリューション • Not meet • 工夫無く使うと圧倒的にコストが高い • オンプレミスからのリプレイスが大変
- 17. #denatechcon マルチクラウド化へ 1/3 • publicクラウドへの集約は多くの要件を満たせる • オンプレミスでは多くの課題が解決できない • publicクラウドの長所は活かし短所は克服 • コストコントロールの徹底 • 多様化には部分最適ではなく全体最適で対応 • 選択と集中 • DeNAは ”事業会社” • 事業開発/モノづくりに専念するのが本質 • publicクラウド事業者と同じ道を辿る必要はない • 3年後にシステム基盤をマルチクラウド化 • 基本はIaaS
- 18. #denatechcon マルチクラウド化へ 2/3 • publicクラウドへの集約は多くの要件を満たせる • 3年後にシステム基盤をマルチクラウド化 • きっちり準備をしてからリプレイス（1年弱の準備期間） • 安定運用とコストコントロールの両立 • オンプレミス環境はゼロへ • 資産管理，ラック管理，修理対応などの業務から解放 • エンジニアのキャリア/モチベーション向上に繋げにくい業務 • 厳選した複数クラウドの併用 • トータルシステムコストの圧縮 • publicクラウド基盤に対する耐障害性の確保 • 基本はIaaS
- 19. #denatechcon マルチクラウド化へ 3/3 • publicクラウドへの集約は多くの要件を満たせる • 3年後にシステム基盤をマルチクラウド化 • 基本はIaaS • システムコスト，品質面から基本はIaaSを選択 • 既存のオンプレミスの運用ノウハウも活用可能 • 優位性がある場合はPaaS/SaaS/FaaSも利用 • システムコストや運用工数のトータルで判断 • Amazon Aurora • Google App Engine，Google BigQuery • セキュリティ，コンプライアンス関連のマネージドサービス
- 21. #denatechcon システム本部新体制のキックオフ • 18/04に体制変更 • 新任の本部長と部長 • DeNAのシステム基盤のロードマップの必要性 • DeNA全社の技術戦略の重要な要素 • エンジニアリング組織作りの方向性と必要なアクション • 経営としてどこにシステム投資をすべきかの道標 • ターゲットは3年，ただし当然その先も見据えて
- 22. #denatechcon インフラ部門マネージャでの議論 • ディスカッション • 5名の検討メンバ，週1〜2回のミーティング • 完全にゼロからの検討 • publicクラウド集約のコスト試算は継続的に実施 • システム基盤の現状，周辺環境，課題の明確化まではスムーズ • 当初は折衷案が優勢 • 個々のサービスの取り扱いに議論が発散（部分最適に陥りがち） • リプレイス工数とコストもネガティブイメージ • 方向性を示す強力なメッセージの必要性 • 結局，今と何も変わらないのでは？ • 経営戦略上の判断の曖昧さを回避
- 23. #denatechcon インフラ部門メンバの意思統一 • 部門内に進捗を共有 • 検討ステータスとスケジュール • システム基盤の現状，周辺環境，課題 • 内容FIX後にメンバから意見収集 • 驚きはあったが目立ったネガティブ反応は無し • 失われるノウハウへの懸念 • それは本当にDeNAにとって必要なものか？ • 先行して詳細に検討開始 • publicクラウドのコストコントロール施策 • publicクラウド全体設計 • システム基盤のpublicクラウド最適化
- 24. #denatechcon 経営層とのコミュニケーション • 経営層との対話 • 本部長（執行役員）と高頻度ですり合わせ • ラフ案の段階から，本部長からCEOにも都度相談 • 「もっとサービスを良くしたい」という想いは同じはず • しかし，見ている目線が違いすぎると話が噛み合わない • 日頃からコンテキストを共有し続けることが非常に重要 • 全社方針の意義 • 経営会議への承認附議 • 全エンジニアが同じ方向に向かって進むことができる • 現場エンジニア間での局所的な議論を回避
- 25. #denatechcon 事業部とのコミュニケーション • エンジニアボード • 各事業の技術責任者のコミッティで全事業領域をカバー • ある程度固まった段階で先行して相談 • 各担当事業における意向と課題の確認 • 全社への周知 • エンジニアだけでなく全社員に向けてメール • 経営判断を経た全社方針である旨を伝達 • リプレイススケジュール設計 • IT基盤部の担当エンジニアから事業部へ相談開始 • 各事業の状況も鑑みてスケジュール設計 • 2018/12末までに全事業分のスケジュールまとめ
- 27. #denatechcon 移行プロジェクトスケジュール 18/04 19/04 20/04 経営承認 本格移行開始 大部分移行完了 18/06 コストコントロール 基盤設計/実装 本格移行 完全移行 FY2018〜 移行準備期 publicクラウド全体設計 システム基盤のクラウド最適化 コストコントロール施策の実施 リプレイススケジュール設計 FY2019〜 本格移行期 コストコントロールされた状態 大半のシステムをクラウド移行 FY2020〜 仕上期 高難易度なシステムの移行 システム基盤の洗練 検討 通常運用 / 継続的改善
- 28. #denatechcon publicクラウド全体設計 • ネットワーク • オフィス/オンプレミス/publicクラウド間のプライベート通信 • アドレス設計，フィルタ設計（Firewall, ACL, SecurityGroup） • セキュリティ • 認証/認可基盤（統合ID管理, 二要素認証, SSO, LDAP） • セキュリティ標準モデル策定 • セキュリティ監査自動化 • アカウント作成時のセキュリティ標準自動キッティング • クラウド内アカウント（IAM, root）の管理効率化 • アカウント管理 • publicクラウド上のアセット管理システムの開発 • アカウント/VPCの粒度，命名規則などルール策定
- 29. #denatechcon システム基盤のクラウド最適化 • システム基盤運用の課題を分析 • 中心的な課題は「運用工数の不足」 • 対応可能な要因について解決していく • 最適化への取り組み • サーバ管理，Config管理 • ライフサイクル管理(作成/S-in/out/削除) • サーバ環境構成，NW環境構成 • Internal DNS • アラート管理/メトリクス監視/機能監視 • オートスケーリング • 可用性設計，DR設計 • ログ保管 • 運用改善・コーディング
- 30. #denatechcon コストコントロール施策の実施 • publicクラウドコストを半減 • コストコントロールを実現してからリプレイス • 銀の弾丸はやはり存在しない • 複数のコストコントロール施策の地道な積み上げ • オートスケーリング • 中断可能性のある在庫インスタンスの活用 • 徹底的な性能管理によるスペックの適正化 • 最新のスペックへの積極的な換装 • 不要データ/インスタンスの撤去 • 相乗り構成の検討（オンプレミスのノウハウ活用） • コスト/性能比の良いマネージドサービスの活用 • キャパシティのコミットによるディスカウント
- 31. #denatechcon まとめ • DeNAはオンプレミスからマルチクラウドへ • 3,000台規模のオンプレミス環境をpublicクラウドへ • 多様化に向けたシステム基盤 • 部分最適ではなく全体最適で思考 • 選択と集中 • やること/やらないこと，取るもの/捨てるものを明確化 • 必要なことに工数と時間のリソースを集中 • 長所を活かし，短所の克服に集中 • ダイナミックな経験ができる非常に稀有な機会
Hinweis der Redaktion
- あああ
- あああ
- 事業スピードに応え続けるための工数とコストの負担 工数逼迫は変わらず 高いボラティリティへの備えとして在庫バッファも必要(全体の5%程度)
- ゲームDBなどの高IOな環境ではローカルストレージを使わざるをえない 突然cpu.systemの値が継続的に上昇していく，特定のDISKに書き込みができなくなる，など
- ゲームDBなどの高IOな環境ではローカルストレージを使わざるをえない 突然cpu.systemの値が継続的に上昇していく，特定のDISKに書き込みができなくなる，など ボラティリティの高いゲーム＆エンタメ事業と特に親和性が高い