逆らえない大きな流れ: 次世代のエンタープライズアーキテクチャ
6 likes2,476 views
Apache Mesos、Apache Hadoop、Apache Spark + カスタムエンタープライズアプリケーション: この組み合わさったスタックは、個々のスタックの要素の合計よりもはるかに価値が高い。Mesosはデータセンター全体のリソース管理を可能にし、Hadoopは分散データストアとスケーラブルな処理基盤を提供、Sparkはインメモリ、ディスクベースの処理の両方でストリーミング処理も含め優れた性能を発揮する。これらすべての要素にカスタムエンタープライズアプリケーションを組み合わせると、データセンターは極めて順調に運用可能なマシンになる。このとき、このソフトウェアスタックは無限の柔軟性をデータセンター全体にもたらすだろう。Jim ScottによるStrata + Hadoop World Barcelona 2014の講演より。
逆らえない大きな流れ: 次世代のエンタープライズアーキテクチャ
- 1. ® © 2014 MapR Technologies 1 ® © 2014 MapR Technologies 次世代のエンタープライズアーキテクチャ Jim Scott, Director, Enterprise Strategy & Architecture Strata Barcelona – 2014 年 11 月 逆らえない大きな流れ:
- 2. ® © 2014 MapR Technologies 2 アジェンダ • 現状 – これまで – これから • 次世代のエンタープライズアーキテクチャ • 具体的な実装 • ビジネス上の意義
- 3. ® © 2014 MapR Technologies 3© 2014 MapR Technologies ® 現状
- 4. ® © 2014 MapR Technologies 4 未来に備えてこれまでを振り返る • データセンターを構築
- 5. ® © 2014 MapR Technologies 5 未来に備えてこれまでを振り返る • データセンターを構築 • サーバは静的に分割され、 分離されている
- 6. ® © 2014 MapR Technologies 6 未来に備えてこれまでを振り返る • データセンターを構築 • サーバは静的に分割され、 分離されている • このサイクルを脱したいのであ れば、分割の仕切りを取り払い 動的にしなければならない
- 7. ® © 2014 MapR Technologies 7 分割する理由を理解する • リソースの分離 – トラブルシューティングの助けになる – 分析チームが本番業務に影響を与えないようにする • アプリケーションの最大スループット – リソース量の保証（最大値）: 計算資源、メモリ、ストレージ • ビジネスの継続 – 何を、いつ、どこにバックアップしたかを正確に把握する – 完璧に行う、もしくはテストすることは難しい
- 8. ® © 2014 MapR Technologies 8 ワークロード分離の問題点 • サーバの分離はハードウェアの利用効率の低下を招く – 容量とエネルギーの無駄遣い • 必要な処理を行うサーバにデータを移動するのに複雑な処理が要る – 追加のモニタリングを含む、業務への影響 – 移動に伴う時間の遅延（リアルタイムに処理できない） – 問題発生時のトラブルシューティングに必要な時間 • 開発、テスト、本番環境のすべてを完全に検証するのは難しい – それぞれの環境は異なる構成、サイズ – 同一の設定ではない
- 9. ® © 2014 MapR Technologies 9 これからのゴール • 存在するすべてのハードウェアを活用する • 異なる方法でリソース分離を行う • 運用管理プロセスを改善する • 開発→テスト→本番の移行プロセスを修正する • リアルタイムなビジネスの継続をサポートする
- 10. ® © 2014 MapR Technologies 10© 2014 MapR Technologies ® 次世代の “最後の” エンタープライズアーキテクチャ
- 11. ® © 2014 MapR Technologies 11 次世代のエンタープライズアーキテクチャ • 動的な計算リソース • 共通ストレージプラットフォーム • リアルタイムアプリケーションサ ポート • 柔軟なプログラミングモデル • デプロイメント管理 • ソリューションベースアプローチ • 業務のためのアプリケーション * プラガブルなアーキテクチャ 分散 ファイルシステム エンタープライズ アプリケーション グローバル リソース管理
- 12. ® © 2014 MapR Technologies 12 実現のためのテクノロジ グローバル リソース管理 分散 ファイルシステム エンタープライズ アプリケーション Mesos + YARN MapR-FS HDFSS3 Web サーバ ビジネス アプリケーション
- 13. ® © 2014 MapR Technologies 13 このアーキテクチャの呼び名は…
- 14. ® © 2014 MapR Technologies 14
- 15. ® © 2014 MapR Technologies 15 名前の由来 • Z は英語ではアルファベットの最後の文字だが、 ゼータはギリシャ語のアルファベットでは最後 の文字ではない – ただし、これは皆が必要とする最後の一般化された アーキテクチャ • ギリシャ語のアルファベットでは 6 番目の文字 – 六角形は 6 つの取り囲む要素を持つ • ゼータは数字の 7 を表す – 本アーキテクチャには合計 7 つのコンポーネント – コンポーネントはグローバルリソースマネージャと共 に動作する
- 16. ® © 2014 MapR Technologies 16 ゼータアーキテクチャの由来の話 • Jim Scott により概念が洗練された – 優れた図式の作成 – 名付け親 – 概念のドキュメント化 • 完全に新しい概念ではない – Google が実質的にこれらのテクノロジの概念 を開発した – Google はこのような形でまとめて議論を行っ たことはなかった
- 17. ® © 2014 MapR Technologies 17 Google におけるゼータアーキテクチャ グローバル リソース管理 分散 ファイルシステム エンタープライズ アプリケーション Borg & Omega GoogleFS HTTP サーバ GMail
- 18. ® © 2014 MapR Technologies 18© 2014 MapR Technologies ® 具体的な実装
- 19. ® © 2014 MapR Technologies 19 Web サーバログ • Web サーバがログを生成 • ローカルディスクに格納 – ログは定期的にローテーショ ンされる • 別サーバに転送 • ログに対しジョブを実行
- 20. ® © 2014 MapR Technologies 20 Web サーバログ • Web サーバがログを生成 • 分散ファイルシステムに格納 – ログはローテーションされる – ログはローテーション前でもサーバ 障害に耐性を持つ – ログは即時に分析対象として使用 可能になる • ログに対しジョブを実行 – データ局所性を持つ
- 21. ® © 2014 MapR Technologies 21 広告プラットフォーム
- 22. ® © 2014 MapR Technologies 22 広告プラットフォーム - シンプルに
- 23. ® © 2014 MapR Technologies 23 ゼータにおける広告プラットフォーム
- 24. ® © 2014 MapR Technologies 24© 2014 MapR Technologies ® ビジネス上の意義
- 25. ® © 2014 MapR Technologies 25 既存システムとの統合 • NFS のような標準を使用して既存システムと接 続する • 企業内で使われている既存の標準に合わせる ことができるプラガブルなセキュリティモデル • このモデルで全てを運用できる訳ではない – Oracle, DB2, SQL Server, PostgreSQL, MySQL • これらはリソース管理下に置かれることや、コンテナ、 分散ファイルシステムをサポートしないことが多い • このアーキテクチャ上のアプリケーションは引き続きこ れらを使うこともあり得る • もしこれらがテクノロジに対応し始めれば状況は変わる ®
- 26. ® © 2014 MapR Technologies 26 データセンターを再考 • すべてのサーバ – Mesos を稼働 – 分散ファイルシステムに参加 • リソースの動的割り当て – Web サーバのスピンアップ – カスタムビジネスアプリケーション – ビックデータ分析 • データ局所性 – データの移動は行わない – データが生成された場所で格納し処理を行う
- 27. ® © 2014 MapR Technologies 27 シンプル化したアーキテクチャ • 可動部分をより少なく – 問題を引き起こす可能性を減らす • より優れたリソース利用効率 – どんなアプリケーションも必要に応じてスケールアップ／スケールダウン • 共通のデプロイメントモデル（新しい分離モデル） – 環境間（開発、テスト、本番）で再現可能 • 共有ファイルシステム – クラスタ内のどこででもデータを利用可能 – ビジネスの継続性をシンプルに
- 28. ® © 2014 MapR Technologies 28 ビジネスの継続 • 回復力 – 冗長性 – 高可用性 – 予備容量 • 復旧 – スナップショット – ディザスタリカバリ • 緊急時対策 – 予期せぬ事態に対する保護 – マルチサイト運用能力 本番 WAN 本番 研究 データセンター1 データセンター2 WAN EC2
- 29. ® © 2014 MapR Technologies 29 プラットフォーム横断のセキュリティとコンプライアンス • 認証（Authentication）、認可（Authorization）、監査（Audit） – ユーザおよびジョブ – すべてのティア • データ保護 – サーバ間のワイヤレベル暗号化 – マスキング • 法規制の遵守 – “古い” データの自動的な有効期限切れ処理 – 分散ファイルシステムによるデータ局所性のサポート
- 30. ® © 2014 MapR Technologies 30 最終的な利益 • 運用コスト（OPEX）の削減 – 容量とデータセンタースペースの利用効率向上 • 資本コスト（CAPEX）の削減 – 必要とされるハードウェアがより少なくなる • 開発期間の短縮 – 合理化されたデプロイメント – 一貫性があり予測可能な環境に • 競争優位性の提供 – プラットフォームのスケールを通じて – 性能の改善
- 31. ® © 2014 MapR Technologies 31 まとめ • 貴重な時間と予算の節約 • ビジネスの継続能力の強化 • Google はすでに何年も実践している – リアルタイムは Google が行う全てにおいて最重要 • 我々すべてにとって今こそ Google スケールで動かす時 – テクノロジは揃っており、うまく協調して動く – このアーキテクチャを実現するには内部でのプロセスの変革が必要 • このアプローチが新たに “伝統的な” 考え方になる – 競合に先を越されないように
- 32. ® © 2014 MapR Technologies 32 ゼータアーキテクチャを実装するために進みましょう
- 33. ® © 2014 MapR Technologies 33 Q&A @kingmesal maprtech jscott@mapr.com Engage with us! MapR maprtech mapr-technologies