ケーススタディ: 5 - Dress4win
会社概要
Dress4win は、Web サイトとモバイル アプリケーションを使用してユーザーが個人のワードローブを整理および管理できるように支援する Web ベースの会社です。同社はまた、ユーザーとデザイナーや小売業者を結び付けるアクティブなソーシャル ネットワークを構築しています。同社は、広告、e コマース、紹介、フリーミアム アプリ モデルを通じてサービスを収益化しています。このアプリケーションは、創業者のガレージにある数台のサーバーから、コロケーション データ センターにある数百台のサーバーとアプライアンスに成長しました。ただし、インフラストラクチャの容量は、アプリケーションの急速な成長に対応できなくなっています。これは、この成長と、より迅速に革新したいという同社の願望によるものです。
Dress4Win はパブリック クラウドへの完全な移行に取り組んでいます。
ソリューションコンセプト
Dress4win は、クラウドへの移行の第一段階で、開発環境とテスト環境を移行しています。また、現在のインフラストラクチャが 1 か所にあるため、災害復旧サイトも構築しています。アーキテクチャのどのコンポーネントをそのまま移行できるか、また、どのコンポーネントを移行前に変更する必要があるかは不明です。
既存の技術環境
Dress4win アプリケーションは、単一のデータ センターから提供されます。すべてのサーバーは Ubuntu LTS v16.04 を実行します。
データベース:
MySQL。ユーザーデータ、インベントリ、静的データ用の 1 つのサーバー:

- MySQL 5.8
- 8コアCPU
- 128 GBのRAM
- 2x 5 TB HDD (RAID 1)
メタデータ、ソーシャル グラフ、キャッシュ用の Redis 3 サーバー クラスター。各サーバーは次のようになります。

- レディス3.2
- 4コアCPU
- 32GBのRAM
コンピューティング:
マイクロサービス ベースの API と静的コンテンツを提供する 40 台の Web アプリケーション サーバー。

- トムキャット - Java
- ングクス
- 4コアCPU
- 32 GB の RAM
20 台の Apache Hadoop/Spark サーバー:

- データ分析
- リアルタイムのトレンド計算
- 8コアCPU
- 128 GBのRAM
- 4x 5 TB HDD (RAID 1)
メッセージング、ソーシャル通知、イベント用の 3 つの RabbitMQ サーバー:

- 8コアCPU
- 32GBのRAM
その他のサーバー:

- Jenkins、監視、要塞ホスト、セキュリティ スキャナー
- 8コアCPU
- 32GBのRAM
ストレージアプライアンス:
VMホスト用のiSCSI

ファイバーチャネル SAN - MySQL データベース

- 合計 1 PB のストレージ、400 TB の空き容量
NAS - 画像ストレージ、ログ、バックアップ

- 合計 100 TB のストレージ、35 TB の空き容量
ビジネス要件
スケールされた生産の同等性を備えた信頼性が高く再現可能な環境を構築します。

セキュリティとアイデンティティおよびアクセスのセットを定義し、それに従うことでセキュリティを向上させる

クラウドの管理 (IAM) のベスト プラクティス。
新しいリソースを迅速にプロビジョニングすることで、ビジネスの俊敏性とイノベーションのスピードを向上させます。

クラウドでのパフォーマンスのためにアーキテクチャを分析および最適化します。

技術要件
クラウド内に非本番環境を簡単に作成できます。

クラウドでリソースをプロビジョニングするための自動化フレームワークを実装します。

オンプレミスにアプリケーションを展開するための継続的な展開プロセスを実装する

データセンターまたはクラウド。
緊急時に本番環境からクラウドへのフェイルオーバーをサポートします。

伝送中および保存中のデータを暗号化します。

実稼働データセンターとクラウド間の複数のプライベート接続をサポート

環境。
エグゼクティブステートメント
投資家は、現在のインフラストラクチャで拡張性とコスト抑制ができるか心配しています。また、競合他社がパブリック クラウド プラットフォームを使用して先行投資を相殺し、より優れた機能の開発に集中できるのではないかとも懸念しています。当社のトラフィック パターンは朝と週末の夕方に最も多く、その他の時間帯は容量の 80% がアイドル状態です。
当社の設備投資は現在、四半期予測を上回っています。クラウドへの移行により、当初は支出が増加する可能性がありますが、次のハードウェア更新サイクルまでに完全に移行できると予想しています。パブリック クラウド戦略の今後 5 年間の総所有コスト (TCO) 分析では、現在のモデルに比べて 30% ～ 50% のコスト削減が達成されます。
この質問については、Dress4Win のケース スタディを参照してください。ソリューションを移行する前に、オンプレミスのアーキテクチャがビジネス要件を満たしていることを確認する必要があります。
オンプレミスのアーキテクチャにどのような変更を加えるべきでしょうか?

会社にはネットワーク チームと開発チームがあります。開発チームは、機密データを含む Compute Engine インスタンスでアプリケーションを実行します。開発チームには、Compute Engine の管理者権限が必要です。会社では、すべてのネットワーク リソースをネットワーク チームが管理する必要があります。開発チームは、インスタンス上の機密データにネットワーク チームがアクセスすることを望んでいません。どうすればよいでしょうか。

アプリケーションは分析のためにログを BigQuery に書き込みます。各アプリケーションには独自のテーブルが必要です。
45 日以上経過したログはすべて削除する必要があります。ストレージを最適化し、Google の推奨プラクティスに従う必要があります。どうすればよいでしょうか?

Google Compute Engine 仮想マシンから Google BigQuery に接続するための Python スクリプトを作成します。スクリプトは、BigQuery に接続できないというエラーを出力します。スクリプトを修正するにはどうすればよいでしょうか。

Google Compute Engine 上の本番データベース仮想マシンには、データ ファイル用の ext4 形式の永続ディスクがあります。データベースのストレージ容量が不足しつつあります。
最小限のダウンタイムで問題を解決するにはどうすればよいでしょうか?