[aurora事例祭り]毎日新聞ニュースサイトをクラウド化～amazon aurora...

Copyright THE MAINICHI NEWSPAPERS. All rights reserved.

毎⽇新聞ニュースサイトをクラウド化〜Amazon Aurora 導⼊事例紹介〜

毎⽇新聞社デジタルメディア局〒100-8051 東京都千代⽥区⼀ツ橋１-１-１

2017.3.7


会社株式会社毎⽇新聞社

部署デジタルメディア局デジタルビジネスグループ

チームデベロップメントチーム

名前森雄司（もりゆうじ）／４０代中半

担当システム設計／開発現場監督／ AWS構築及び運⽤

資格 AWS 認定ソリューションアーキテクト – アソシエイト

好きなAWSサービス AWS Lambda、 DynamoDB、Amazon CloudWatch

AWS Summit Tokyo 2016で登壇「毎⽇新聞ニュースサイトをクラウド化〜AWSだからできた、SIerレスなシステム内製化〜」

http://media.amazonwebservices.com/jp/summit2016/3A-05.pdf

2

プロフィール


会社概要・サービス紹介


4

会社概要

• 会社名– 毎⽇新聞社

• 事業内容– ⽇刊紙の発⾏– デジタルメディア事業– 雑誌・書籍の発⾏– スポーツ⽂化事業– その他各種の事業

• 創刊– 1872年(明治5年)2⽉21⽇– 今年創刊１４５年⽬


5

デジタルメディア局の主な事業紹介

ニュースサイト運営

法⼈向けニュース提供過去記事写真データベース

・⼤⼿ポータル・携帯キャリア・キュレーションアプリ・電光掲⽰板など様々な媒体に適した形でコンテンツを提供


6

毎日新聞ニュースサイトの紹介

• 最新ニュース、解説・コラム、デジタルオリジナルコンテンツも提供

• 写真特集や動画ニュースも展開• スマートフォンサイトへの対応• スマートフォン専⽤アプリの提供


7

デジタルメディア局の主な事業紹介


8

電子新聞サービス「デジタル毎日」• ２０１５年６⽉からサービスを開始

• 毎⽇新聞ニュースサイトの記事が、全て読める有料サービス

• 紙⾯イメージそのままが閲覧できる紙⾯ビューワー

• 経済・医療プレミアコンテンツの提供

• イベントやプレゼンなどのご優待特典

• 朝・昼・⼣のニュースメールと号外メールの配信

• ウォール・ストリート・ジャーナルも読める


システム紹介


10

システム構成図

AmazonS3

Elastic Load Balancing

Auto Scaling group

Amazon EC2

AmazonS3

Amazon CloudSearch

Amazon CloudFront

Amazon ElastiCache

Amazon Aurora

Elastic Beanstalk

Elastic Beanstalk

Elastic Beanstalk


AmazonSQS

Auto Scaling group

Amazon EC2


Amazon EC2

CMSElastic IP

PROXY

WEB

CloudSearch登録処理

画像変換処理

新聞製作システムデータ受信登録処理

他社連携システム

ユーザー

新聞製作システム

編集者


11

主な機能（１／４）～コンテンツ作成機能（CMS）～

AmazonS3


Auto Scaling group

Amazon EC2

AmazonS3

Amazon CloudSearch

Amazon CloudFront

Amazon ElastiCache

Amazon Aurora

Elastic Beanstalk

Elastic Beanstalk

Elastic Beanstalk


AmazonSQS

Auto Scaling group

Amazon EC2


Amazon EC2

CMSElastic IP

PROXY

WEB


画像変換処理



ユーザー


編集者


12

主な機能（２／４）～新聞製作システム連携機能～

AmazonS3


Auto Scaling group

Amazon EC2

AmazonS3

Amazon CloudSearch

Amazon CloudFront

Amazon ElastiCache

Amazon Aurora

Elastic Beanstalk

Elastic Beanstalk

Elastic Beanstalk


AmazonSQS

Auto Scaling group

Amazon EC2


Amazon EC2

CMSElastic IP

PROXY

WEB


画像変換処理



ユーザー


編集者


13

主な機能（３／４）～バックエンド自動処理～

AmazonS3


Auto Scaling group

Amazon EC2

AmazonS3

Amazon CloudSearch

Amazon CloudFront

Amazon ElastiCache

Amazon Aurora

Elastic Beanstalk

Elastic Beanstalk

Elastic Beanstalk


AmazonSQS

Auto Scaling group

Amazon EC2


Amazon EC2

CMSElastic IP

PROXY

WEB


画像変換処理



ユーザー


編集者


14

主な機能（４／４）～コンテンツ（ニュース）提供機能～

AmazonS3


Auto Scaling group

Amazon EC2

AmazonS3

Amazon CloudSearch

Amazon CloudFront

Amazon ElastiCache

Amazon Aurora

Elastic Beanstalk

Elastic Beanstalk

Elastic Beanstalk


AmazonSQS

Auto Scaling group

Amazon EC2


Amazon EC2

CMSElastic IP

PROXY

WEB


画像変換処理



ユーザー


編集者


15

Amazon Auroraの利用

AmazonS3


Auto Scaling group

Amazon EC2

AmazonS3

Amazon CloudSearch

Amazon CloudFront

Amazon ElastiCache

Elastic Beanstalk

Elastic Beanstalk

Elastic Beanstalk


AmazonSQS

Auto Scaling group

Amazon EC2


Amazon EC2

CMSElastic IP

PROXY

WEB


画像変換処理



ユーザー


編集者

Amazon Aurora


Amazon Auroraの採用について


17

採用の理由

ü⾼パフォーマンス

üメンテナンスビリティ

üコスト

üMySQLとの⾼い互換性

ü移⾏が簡単


18

採用の理由①

• ⾼パフォーマンス–⾼スループット

• MySQLと⽐較して最⼤５倍のスループット

–低レイテンシーのリードレプリカ• 最⼤１５個のレプリカが作成可能で、レプリカのタイムラグは通

常数ミリ秒


19

採用の理由②

• メンテナンスビリティ– フルマネージドサービスによる構築・保守・運⽤の軽減

• バックアップ

• チューニングレス

• 短時間でのフェイルオーバー

• ゼロダウンタイムパッチ


20

採用の理由③

• コスト– 設計当初の構成は、「Amazon RDS for MySQL」での「Master + Slave +

ReadReplica」の構成。この構成だと、最終的に１TBのストレージが必要となる場合は、使⽤量に関係なく最初から「Master(1TB) + Slave(1TB) + ReadReplica(1TB)×2 ＝4TB」とインスタンス数分のストレージ費⽤（⽉額）が必要となる。

– 「Amazon Aurora」の場合は、インスタンス数に関係なく、１ストレージ分の費⽤で済む。また、容量も最低100GB(デフォルト)から使っている分だけ(容量はオートスケーリング)で済むので、最終的にどのくらい必要となるか不透明な、ストレージを購⼊しておく必要もない。

1TB 1TB

1TB 1TB

４TB

Amazon RDS for MySQL

0.1TB 0.1TB

＋使った分

Amazon Aurora

＋ AutoScaling


21

採用の理由④• MySQLとの⾼い互換性

– Aurora東京リージョンのローンチ ⇒ 2015年10⽉– 弊社システムのリリース ⇒ 2015年12⽉

• 「Amazon RDS for MySQL」で設計、アプリケーションを開発– 採⽤を決定 ⇒ 2015年11⽉下旬

• アプリケーションはほぼ開発完了の状態– 動作検証を⾏い、Auroraに変更したのは、システムリリース2週間前

• Auroraを準備し、「Amazon Route 53」のInternal DNSのエンドポイントをAuroraに変更、ミドルウェア、プログラム、開発環境の変更なし。

MySQL

AuroraAmazonRoute 53（Internal）

プログラム

【2015年】 7月 8月 9月 10月 11月 12月

Aurora東京リージョンローンチ

MySQL Aurora開発／テスト

検証

2WAurora

システムリリース


• 移⾏が簡単– 「Amazon RDS for MySQL」から「Amazon Aurora」

への移⾏が簡単• 全てマネジメントコンソールでの操作• 「Amazon RDS for MySQL」のスナップショットを作成し、そ

のスナップショットから「Amazon Aurora」をローンチするだけ。

–新たな移⾏ツールと機能• AWS Database Migration Service• DBスナップショットの共有

22

採用の理由⑤

MySQL Aurora


23

採用による効果

üメンテナンスレス

üトラブルレス

ü技術者・社内利⽤者の意識改⾰


24

採用による効果①

• メンテナンスレス– パラメーターチューニング

• ⾼度で専⾨的な⼈員の確保が不要

– ストレージ容量• 64TBまで、オートスケーリング

– バックアップの⾃動化• 世代管理、ストレージの容量管理• パフォーマンスへの影響

– パッチの適⽤• ゼロダウンタイムパッチ• 適⽤スケジュール設定


25

採用による効果②

• トラブルレス– 2015年12⽉システムリリースから24時間365⽇、本⽇

まで、システムは100%稼働• Auroraの１インスタンスにフォーカスを当てても障害なし

– 経年運⽤による、システムの遅延なし• ⼊⼒時の操作待ち時間• ⼊⼒データの反映時間• レプリケーション• WEBレスポンス


26

採用による効果③

• 技術者・社内利⽤者の意識改⾰・安定したシステム・ストレスのないレスポンス・メンテナンスビリティのよいシステム・etc.

・技術者が安⼼して開発できる環境・社内利⽤者がコンテンツ作成に集中できる環境

・短時間での問題解決、要望対応が可能・サービス追加やサービス改善・CMS機能追加やCMS機能改善

ＰＶアップ


27

今後のAuroraに期待すること• 既に実装済みのクラウド的な機能

• ぜひ、実装して欲しい機能– リードレプリカのオートスケーリング機能– リードレプリカのグルーピング機能

– ストレージ容量のスケーリング– フェイルオーバーインスタンス優先度指定– クラスターエンドポイント（書込み⽤クラスター）

• フェイルオーバー時のエンドポイント変更不要– リードエンドポイント（読込み⽤クラスター）

• 複数のリードレプリカインスタンスに対しロードバランシング

• インスタンスの追加、削除にも対応

サービス Aアプリケーション

サービス Bアプリケーション

Reader EndpointGroup A

Auto Scaling group A

Auto Scaling group B

Reader EndpointGroup B

Aurora


2017.3.7

ご清聴ありがとうございました。

http://mainichi.jp/

[aurora事例祭り]毎日新聞ニュースサイトをクラウド化 ～amazon aurora...

Data & Analytics

[aurora事例祭り]毎日新聞ニュースサイトをクラウド化～amazon aurora...