このページの本文へ

前へ 1 2 次へ

「ぐるなび」のOpenShift採用事例、CoreOS統合方針、IBM/Azureとのクラウド協業などを紹介

レッドハット「コンテナをコモディティにする」2019年度戦略

2018年06月28日 07時00分更新

文● 大塚昭彦/TECH.ASCII.jp

  • この記事をはてなブックマークに追加
  • 本文印刷

ぐるなび、OpenShiftを採用し開発環境のセルフサービス化を実現

 レッドハットでは同日、グルメ情報サービスを提供するぐるなびにおいて、新たなサービス開発環境(PaaS)のインフラにOpenShiftが採用されたことを発表した。説明会では、ぐるなびの開発部門から小川保法氏、湯瀬淳也氏がゲスト出席し、インフラ/開発チーム合わせて250名規模の開発部門がインフラに抱えていた課題、OpenShift採用の理由、今後の展開などを紹介した。

ぐるなび 企画開発本部 開発部門 インフラストラクチャサービスセクション クラウドアーキテクチャグループの小川保法氏

同 企画開発本部 開発部門 技術・開発推進セクション アーキテクトグループ シニアリーダーの湯瀬淳也氏

 インフラを担当する小川氏によると、ぐるなびでは2016年ごろからオンプレミスとパブリッククラウドが連携するマルチクラウドインフラ「Gurunavi Multi Cloud Platform(GMCP)」の検討を開始した。ここでは、より魅力的なサービスを生み出しすために「最新サービスがすぐに使えること」「変化に対して柔軟に対応できること」「開発スピード向上に貢献できること」が、新プラットフォームが実現すべき目標となった。

 この目標に基づいて具体的な“ToBeモデル”を策定すべく、レッドハットのコンサルティングサービスを利用しながら、インフラに関係する全部署へのヒアリングを実施した。その結果、セルフサービス/セルフオペレーションでの柔軟な環境構築、インフラのコード化(Infrastructure-as-Code)による構成管理、スモールスタート可能な環境の実現、新技術を検証する環境の提供、などの要望に集約された。

 新インフラでOpenShiftを採用した理由は、こうした要件をすべて満たすことができたからだと、小川氏は説明する。たとえば、インフラ構成をコンテナで標準化することで開発から本番展開まで同じイメージを利用できること、デプロイやリリースを開発者がセルフサービスで実行できること、インフラ管理者の運用負荷が軽減できること、などだ。

 ただし、ぐるなびがこれまで利用してきた環境は「結合度の高いオンプレミス中心のインフラ」(小川氏)であり、いきなりインフラの全面コンテナ化を図れるわけではない。小川氏は“リフト&シフト”で進める方針だと述べ、まずは第一段階としてWebサーバー群とアプリケーションサーバー群をコンテナ化し、OpenShiftに移すことで「これで一度コンテナ化の恩恵を受けよう」と考えたと話す。今後、新たに開発するサービスではクラウドネイティブなアーキテクチャを採用していき、最終的にはクラウドへ移行することを考えているという。

旧来のシステム構成

OpenShift導入後のシステム構成

 また湯瀬氏は、開発チーム側から見たOpenShift環境のメリットを説明した。旧来の開発環境では、サーバーの払い出しやアカウント設定、NASのマウント、ミドルウェアの追加や設定など、あらゆるインフラ作業をインフラチームにチケットで依頼しなければならなかった。リードタイムが2、3日かかることもあったうえ、日々大量の依頼がなされるため「気軽に依頼できない」雰囲気もあった。

 新しいOpenShift環境ではセルフサービス範囲が拡大したため、こうした課題が大幅に解消された。小川氏によると、新しい開発環境の導入によって、インフラチーム側の工数は約35%、開発チーム側の工数は約65%削減されたという。

旧来の業務範囲(役割分担)

OpenShift導入後の業務範囲

 小川氏は、OpenShiftコンテナ環境の導入が済んだ次段階の展望として、コンテナ化のさらなる促進、パブリッククラウド上のコンテナ基盤との連携、マイクロサービスアーキテクチャの検討などを行っていきたいとした。また、利用者ごとのリソース利用状況やコストの可視化も行っていく方針で、OpenShiftに統合予定のTectonicに「期待している」と語った。

■関連サイト

前へ 1 2 次へ

カテゴリートップへ

  • 角川アスキー総合研究所
  • アスキーカード