DMM.comは「レガシーな」密結合システムからいかに脱却したのか
記事をお気に入りリストに登録することができます。
動画配信や電子書籍などの総合的なデジタルエンターテイメントを手掛ける企業であるDMM.com。同社の各サービスは「レガシー化」した共通モジュールで密結合され、相互接続関係がブラックボックス化してしまっていた。これにより、リリースのスピード向上を阻害し、障害時の原因の特定や切り分けに時間を要していたという。現在、この状態を切り抜ける施策を打った同社は、どのように依存関係を可視化し、「レガシーな密結合状態」から脱却を推進したのか。
それぞれのサービスが密結合し、依存関係が複雑化
動画配信をメインに、40以上の多種多様なサービスを提供するDMM.com。デジタル事業のほかにも、豊洲に「teamLab★Planets TOKYO DMM.com」という体験型のアミューズメントパークを展開し、アフリカで海外事業を展開するなど、バリエーションに富んだ事業を次々と世に送り出している。VRなどを活用し、配信できるコンテンツもリッチになり、デジタル事業を支えるインフラは、ピーク時には200Gbpsを超えるトラフィックを扱うこともある。継続的にサービスを提供するために、オンプレミス、パブリッククラウドを併用したインフラ基盤を構築、運用している。
そんな同社のIT基盤は、これまで各サービスが共通モジュールによって密結合していた。このモジュールは、長く同社のサービスを構成してきた。しかし、いわば“レガシー化”した共通モジュールのせいで、たとえば新しいサービスを開発、リリースする際にミスがあったりした際に、サービス全体に影響が波及してしまう課題があった。
現在、同社では1日に数多くの、新たなコンテンツやサービスなどの更新がある。たとえば、サービスのタイトルが新しくリリースされたときに、新たなコードを書いてデプロイを行うが、その際も共通モジュールに手を加えなければならない。コードを間違えていた、あるいは、それぞれのアクセスが止められてしまうようなコードが含まれていた場合、サービス全体が止まってしまう可能性があった。
リリースのたびに、ほかのビジネスの機会損失を伴うリスクが発生するため、担当者はリリース作業に神経を尖らせる必要があり、これがサービス更新のスピードを下げる一因となっていた。
さらに、それぞれのサービスが密結合し、依存関係が複雑になった結果、障害が発生したときに、原因の特定や切り分けに時間がかかり、復旧に時間を要していた課題もあった。
レガシー化したモジュールの運用は、いつの間にかブラックボックス化し、すべての構造を理解している人がいないため改修が困難になるといった弊害を生んだ。
そこで、共通モジュールを使わない仕組みを作り、デプロイの影響が個別のシステム内で収まるような環境を整備する必要があったのだ。
実は、同社ではこれまで何度か、密結合状態からの脱却にトライしたが、実現に至らなかった経験がある。しかし、サービスのスピーディなリリースは待ったなしのテーマであり、2017年から問題解決に着手した。「共通モジュールからの脱却」「各サービスの分離・独立」をどのように進めていったのだろうか。
この記事の続き ＞＞
・「各サービスの依存関係の可視化」でわかること
・作業時間は8時間から30分に短縮、作業の標準化も実現
・「サービスファースト」のインフラ整備に必要な考え方
・「各サービスの依存関係の可視化」でわかること
・作業時間は8時間から30分に短縮、作業の標準化も実現
・「サービスファースト」のインフラ整備に必要な考え方
今すぐビジネス＋IT会員にご登録ください。
すべて無料！ビジネスやITに役立つメリット満載！
-
ここでしか見られない
1万本超のオリジナル記事が無料で閲覧可能
-
多角的にニュース理解
各界の専門家がコメンテーターとして活躍中！
-
スグ役立つ会員特典
資料、デモ動画などを無料で閲覧可能！セミナーにご招待
-
レコメンド機能
あなたに合わせた記事表示！メールマガジンで新着通知
関連タグ
