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