[レポート] 毎日新聞ニュースサイトをクラウド化 ~AWSだからできた、SIerレスなシステム内製化~ #AWSSummit

[レポート] 毎日新聞ニュースサイトをクラウド化 ~AWSだからできた、SIerレスなシステム内製化~ #AWSSummit

Clock Icon2016.06.06

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

2016/6/1(水) ~ 6/3(金)に開催された「AWS Summit Tokyo 2016」のDay3、General Conference IT Transformation Track「毎日新聞ニュースサイトをクラウド化 ~AWSだからできた、SIerレスなシステム内製化~」を聴講しましたので、そのレポートになります。

セッション説明文

以下、セッションの説明文になります。

毎日新聞社では、ニュースサイト(mainichi.jp)のシステムをAWSに構築しました。これまでSIerと作ってきたシステム構築のノウハウを生かし、AWSで提供されるマネージドサービスを多用することで、SIerなしでもシステムの内製化を実現しました。システムリリースまでの道のりや、AWSだからこそできたシステム構成、さらに、システムの内製化によりもたらされた様々なエピソードをご紹介します。

スピーカーの方の紹介

今回のセッションでは毎日新聞のお二方が登壇しました。

楢本 隆治 氏

株式会社 毎日新聞社 デジタルメディア局 デジタルビジネスグループ マネジメントチーム ディレクター

森 雄司 氏

株式会社 毎日新聞社 デジタルメディア局 デジタルビジネスグループ デベロップメントチーム

さいしょに

楢本氏から、毎日新聞についての話と、AWS導入の背景が語られました。

また、セッションの最初に、SIerさんには挑戦的なタイトルになっていますけれど、あくまでニュースサイトでの話であり、その他のシステムではSIerの方と協力してます、と付け加えられました。

毎日新聞とは

  • 創刊144年の歴史を持つ新聞社。
  • デジタルメディア局は、ニュースサイト「デジタル毎日」運営などを行っています。
    2015年6月から開始。
  • 毎日新聞ニュースサイトの記事をすべて読める有料サービスや、イベントやプレゼントの優待サービス、ニュースメールの配信など。
    ウォール・ストリート・ジャーナルも読めるようになりました。
  • ニュスサイトには、最新ニュース、解説、コラムや、写真特集、動画ニュース。
    原則有料化して、記事閲覧にはメーター制を導入しています。

AWS導入の背景

ニュースサイトのシステム開発の内製化とAWSのクラウドサービスの導入をしました。

内製化の背景

ニュースサイトの有料化に向けて、日々サイトのデザインやシステム改善、新規サービスの投入など、ユーザに満足していただけるサービスを提供したいと思いました。
それを実現するためには、システム開発体制、インフラ作りを内製化しようと思いました。

内製化に向けて

  • 事業部門で開発体制を構築した
    開発人員の確保
  • クラウドサービスの利用した
  • 過去のシステムから脱却した
  • ただし、無理はしない
    システムをシンプルに。必要な物だけを精査した。
    今までのSIerさんにお願いしていた時は、何でもかんでもやろうとした、そしてシステムが複雑になって使いこなせなくなった。

AWSを採用した背景

  • AWS構築経験者がいた
  • 小さなサービスから実績を積んだ
  • マネージドサービスの種類が豊富だった
  • 運用時の負荷がすくなかった
  • 他のクラウドより、開発情報や開発者が多い
    コミュニティがしっかりしている。
  • 急なアクセスにも対応できる
    ヤフーニュースに取り上げられると大量にアクセスが来るが、その場合はオートスケール機能を使うことで対応できるのが、コスト的にパフォーマンスが良かった。
  • AWSのアカウントマネージャのサポートがあった
    システム構築のアドバイスやサポートをしてもらった。

内製化とAWS導入に必要だった思考の変革

  • トラブルの責任を自分たちで取ろうという意識に変わった
    AWSでもトラブルが起きることを前提でシステムを構築した。
    オンプレでトラブルが起きなかったことはない。ただしAWSにしたことで、今までトラブルらしいトラブルはなかった。
  • 詳細な仕様書が作らない
    Redmineでタスクを作って管理してる程度。
  • システムリリースが終了ではなく、そこからがスタート。
  • 自分たちで考える
  • 無理はしない

人員確保とAWSを使った開発に向けた体制づくり

  • 内製化に向けてエンジニアの確保と教育
  • 社内の別セクションに居るSI経験を持ったエンジニア
  • アソシエイトを所持したエンジニア
    今社内には3名有資格者がいます

システム内製化導入の効果

  • 起案からシステム化までのプロセスと時間の短縮
  • 開発費用、運用費用が大幅に削減
  • 根本的な障害が発生しなくなった
  • 障害調査対応の時間が短縮できた

計画実施時のエピソード

AWSの請求がドル払いのため、起案時は1ドル80円台だったが、実施した時は1ドル120円台だったので、予算との差が起きた

  • システム構成の見直し
  • リザーブドインスタンスの購入による大幅削減
  • マネージドサービスの進化による開発軽減
  • トライアンドエラーによるシステムの最適化
  • AWSの価格改定

日本リージョンでの支払いが円払いになってくるれることを期待しています。

社内から◯◯クラウドのほうが安いとの指摘を受ける

  • マネージドサービスの豊富による開発費の削減
  • AWS構築の開発者が多いことによるスキル取得の短縮
  • リザーブドインスタンスによる大幅なコスト削減
  • 障害が起きにくい

これらのことを説明した

新規サービス投入やサービス改善の敷居が下がった

インフラの準備がすぐできることにより、サービスの投入の敷居が下がった。

なぜSIerレスでできたのか

AWSマネージドサービスを利用することにより、専門的知識が不要になった

  • サーバの導入構築運用の心配が減った
  • AWSを使って、さまざまなサービスをスモールスタートさせることができる
  • AWSの知識がなくても開発できる仕組みを作った
  • 無理をしない

デジタル毎日新聞の中身

WordPressやMovableTypeがあるけれど、既成品のカスタマイズではなく自分たちで作った。
これは、ニュース配信という特殊な要件に応えるため。
すべてのシステムをAWS上に構築した。

システムコンセプト

  • 24時間365日サービスを提供できるシステム
    ニュースもライフラインと同じ
  • オペレータに運用ストレスのないCMS
    システム応答速度、利用者にとってのストレスは、日々使うものなので極力なくそうとした
  • 運用保守が容易なシステム
  • 安定稼働するシステム
  • 保守性拡張性の高いシステム
  • 障害より耐障害性を加味したシステム構成

システムの構成と機能

コンテンツ作成機能CMS

  • ELBとEC2で冗長構成
  • ニュースの作成
  • 写真特集の作成
  • 特集コーナー作成
  • ニュースの公開非公開予約
  • テンプレート管理をここで行えるようにしている

新聞製作システム連携機能

  • S3投入からSQSにキューイングして、EBで新聞製作システムデータ受信への登録処理
  • ニュースが自動的に反映する仕組みを作っている

バックエンド自動処理

  • CloudSearch登録処理(EB)
    記事の情報を登録して、サイト内検索などで利用
  • 画像変換処理(EB)
  • S3へ流す

コンテンツ(ニュース)提供機能

  • ELB-ASでスケーラブルに作っている。
  • 外部サービスとの連携はEIPでEC2をProxyにして流す
  • 画像データなどの静的はCloudFrontで配信
    TTLを短くして、急な変更に対応している

SQSを使って、システム間を疎結合にしている。

システム監視

  • AmazonCloudWatchで稼働状況を監視。
    ダッシュボードによく使うメトリックスを登録している
  • AmazonCloudWatchAlarm+AmazonSNSを利用して障害予知
  • AmazonCloudWatchLogsでログを集約
  • 運用監視ソフトウェアによる監視

アプリケーション開発の工夫

  • AWSリソースアクセス容易ライブラリの作成
    AWS経験のないエンジニアも採用できた
  • 処理ごとにリソースを分離
    処理ごとに最適なリソースを割り当てられる。
    プログラムもシンプルになって、クウォリティを向上できた。
    障害が発生しても障害ポイントの特定しやすくなった

Amazon Aurora導入について

中核はAuroraを採用している

  • 2015年10月に東京リージョンにローンチ
  • システムのリリースは2015年12月
  • 導入を決定したのは2015年11月下旬

導入決断のポイント 1.コスト

RDSを使った場合、インスタンス数分のストレージ費用が必要となった。
Auroraならインスタンスに関係なく1ストレージ分の費用で済んだ。
あと、使っている分だけで良かったので、不透明なシステムに導入しやすかった。

導入決断のポイント 2.MySQLからAuroraへの移行が容易だった

RDSのスナップショットからAuroraをローンチするだけでよかった。
200GB程度で4時間程度。

導入決断のポイント 3.MySQLとの高い互換性

DNSエンドポイントを内部で管理していたため、システム側を一切変更する必要がなかった。

高パフォーマンスと多機能

自動バックアップとチューニングレスはものすごく助かっている。

その他のAWSサービス

AmazonVPC、IAM、AWS CertificateManagerも利用している。

今後

より障害の無いシステムへ。

SQS+Lambdaを導入してサーバーレスで安定したシステムにしたい。

Code三兄弟(AWS CodeCommitAWS CodeDeployAWS CodePipeline)を導入したい

まとめ

  • 安定したアプリケーションの開発
  • 作りながらリソースを選定
  • アプリケーションに合わせたリソースの構築
  • 障害を前提としたシステム構成
  • 冗長構成とオートスケーリングで構成
  • マネージドサービスを多用したシステム構成
    インフラの構築に必要だった専門的な知識は殆ど不要になった
    システム保守も容易

おわりに

  • 安定したアプリケーションの開発
  • 障害を前提としたシステムの構成
  • マネージドサービスを多用したシステム構成

内製化によってより良いサービスの提供ができるようになりました。
今後共毎日新聞ニュースサイトをよろしくお願いします。

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.