このページの本文へ

前へ 1 2 次へ

「AWS Solution Days 2017」で披露された国内2社のグローバル先端事例

もうオンプレには戻らない、リクルートとドコモがデータ分析基盤をAWSへ移す理由

2017年08月08日 10時30分更新

文● 五味明子 編集 ● 羽野/TECH.ASCII.jp

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

スケールの壁に悩みAWSへ移行、PB級のRedshiftを構築:NTTドコモ

 20以上のデータソースから吸い上げられる分析データの量は1日あたり10テラバイト以上(圧縮済み)、SQLによる分析を行うユーザーの数は1000人以上で、psqlやODBC、RなどのSQLクエリがつねに10程度は実行されている—。NTTドコモは現在、この巨大なデータ分析基盤をAmazon Redshiftを中心にしたサービスと組み合わせ、AWSクラウド上に構築している。利用するRedshiftのインスタンスは「ds2.x8larage」、現行世代で最上位のスペック(vCPU×36、メモリ244GB)であり、160テラバイト(ds2.x8larage×10)と2ペタバイト(ds2.x8larage×125)×2という超巨大容量のデータベースクラスターを運用している。

NTTドコモ サービスイノベーション部 主査 佐々木純氏

 NTTドコモでは、もともとNetezzaやGreenplumなどオンプレミスのデータウェアハウス環境を運用していたが、データのサイロ化や散在、利用者の限定などオンプレミスであれば必ずぶち当たる“スケールの壁”に悩み、「多種データの一元収集と部門横断利用のしくみを備えた分析基盤が必要」(NTTドコモ サービスイノベーション部 主査 佐々木純氏)と判断。2014年からAWSに移行し、現在に至っている。

 「トータルコスト、セキュリティ、パフォーマンス、メンテナンス性といった分野で同環境のオンプレミスと総合的に評価した結果、Redshiftの圧倒的な性能や機能追加に要する時間の短さ、運用性などからAWSへ舵を切る決断をした」(佐々木氏)。

 もっとも移行に当たってはすべてがスムースに運んだわけではなく、佐々木氏は、次のような試行錯誤があったと振り返る。

  • 最終的な意思決定に至るまで数十回の議論を含む社内調整、セキュリティリスクや費用対効果などに対する社内からの不安(「しゃべってコンシェル」など別システムでのAWS利用実績や既存の成果による価値の確信などから説得)
  • 構築時のメンバー4名がAWS経験ゼロ(構築コンサルや社内AWS有識者のサポートに加え、クラウドならではのトライ&エラーのしやすさで即時実装)

NTTドコモでは2014年からAmazon Redshiftを核としたビッグデータ分析基盤を社内に構築している

 しかし結果的には「移行を決断してからは、未経験のメンバーでも4カ月で構築が完了した」(佐々木氏)という。とくにセキュリティに関しては、NTTドコモの280にもおよぶ社内基準をすべてクリアし、さらに「AWSの豊富なセキュリティ機能(VPC、SG/NACL、DX、IAM、MFA、KMS、Croud Trailなど)をフル活用し、論理的プライベート空間を構築」(佐々木氏)できたことで、オンプレミスでは難しい対策(外部攻撃だけではなく内部犯行の防止、運用メンバーが変化しても継続できるしくみ、閲覧可能な情報のコントロール、システム外へのデータ取り出し制限など)までも実現できている。「仮に内部に悪意をもった人物がいても、単独では悪さができないしくみをAWS上では構築することができる」(佐々木氏)。

Redshiftのアップデートを味方につける

 ペタバイトクラスのRedshift構築/運用事例として、NTTドコモのケースは国内だけではなくグローバルでも広く知られているが、運用開始後から当初は想定していなかった問題に悩まされるケースも少なくないという。

 例えば現在では修正されているが、当初はRedshiftの最大スキーマ数が256しかなく、1人あたり1スキーマで使っていたら枯渇してしまったこともある。非アクティブユーザーのスキーマをサイレント削除するなどして対応したが、「テーブルを大量に使うユーザーには日頃から注意したほうがいいかもしれない」(佐々木氏)という。

 また、Redshift導入後は社内の利用者(分析者)が拡大したが、その分、SQL初心者が叩きがちな“不適切なクエリ”も増大し、「超巨大テーブルからSELECTを引っ張る、無謀なJOINをかける、日単位テーブルを全UNIONする、などわりと手がつけられない状態になった」(佐々木氏)ことも多々あり、こうした場合は、勉強会でのレクチャーや個別指導で乗り切っている。

 もっともこうした課題も、AWSによるアップデートで劇的に改善されるケースも多いと佐々木氏は指摘する。「AWSは常に進化する存在なので、継続的にセキュリティや性能向上をはかることができる。だからこそユーザー側は、そのアップデートに応じて設計を柔軟に変えていかなくてはならない」(佐々木氏)。

 尚、佐々木氏が指摘したRedshiftにおける“インパクトの大きかったアップデート”は以下の通り。

  • LOAD/UNLOADのREVOKE制御
  • インスタンス性能の向上(ds1→ds2)
  • S3用のVPCエンドポイント
  • Redshift - S3のVPCエンドポイント対応
  • CTASの自動圧縮
  • スキーマ数の拡大(256→9900)
  • Redshift Spectrumの登場

 このほかに、NTTドコモからAWSへの要望として「PostGISのサポート」、「最大テーブル数(現在は9900)の拡大」を挙げているという。また、Spectrumへの強い関心も示しており、「今後は“破産しないSpectrumの活用法”を考えていきたい」(佐々木氏)としている。

オンプレミス時代のデータ分析基盤構築には膨大な手間と時間を要していたが、AWSに移行したことでそれが数クリックに短縮された。一度でもこれを体験したら「オンプレミスには戻らない」のも当然といえる

 このようにいくつかの課題はあるものの、佐々木氏は「個人的にはもうプロジェクトをオンプレミスで始めることはない」とあらためて強調する。「オンプレミス時代はシステム構築時に半年~1年かかっていた工程が、AWSクラウドでは数クリックに短縮された。正直、“今までの苦労はいったい何だったんだろう”と夢を見ているかのような気持ちになったことを覚えている。クラウドはすでに不可逆な流れであり、オンプレミスの時代に戻ることはない」という同氏の言葉には、AWSとともに自分たちもまた成長していくという選択をしたことが見えてくる。

前へ 1 2 次へ

カテゴリートップへ

本記事はアフィリエイトプログラムによる収益を得ている場合があります

アクセスランキング

  1. 1位

    TECH

    訓練だとわかっていても「緊張で脇汗をかいた」 LINEヤフー、初のランサムウェア訓練からの学び

  2. 2位

    ITトピック

    若手が言わない“本音の退職理由”上位は/「データ停止は景気後退よりも企業の脅威」6割/クライアントに告げずAI活用するフリーランス、ほか

  3. 3位

    ビジネス・開発

    最悪のシナリオは「フィジカルAI」による基幹産業の衰退 日本の勝ち筋は、“同期技術”と“ドメイン知識”

  4. 4位

    Team Leaders

    ファイル名が命名規則に合っているかの自動チェック、Power Automateのフローで実現しよう

  5. 5位

    TECH

    糖尿病超早期を採血なしで検出、予防へ! 代謝や臓器のつながりに着目した予防法開発

  6. 6位

    データセンター

    液冷技術の最先端が集うイノベーションラボ「DRIL」、印西のデータセンターに現わる

  7. 7位

    ビジネス

    廃校がAIの心臓部に!? 地方の遊休施設を「AIデータセンター」に生まれ変わらせるハイレゾの挑戦がアツいぞ

  8. 8位

    TECH

    “GPUなし”ノートPCで動くLLMで、ローカルAIエージェントを自作する

  9. 9位

    Team Leaders

    バックオフィス業務もAIに“丸投げ” マネーフォワードが「Cowork」機能を2026年7月に投入へ

  10. 10位

    TECH

    合成ゴムが及ばない天然ゴムの高性能のメカニズムを、現象発見から100年後に解明

集計期間:
2026年04月09日~2026年04月15日
  • 角川アスキー総合研究所