日経電子版のAWS移行

Transcript

1. 1.

   日経電子版のAWS移行 日本経済新聞社 デジタル編成局 西馬一郎 2015/10/15 Cloudpack User Group MeetUp 2015

2. 2.

   自己紹介 • 西馬一郎（ニシウマ イチロウ） • 2002年入社 • 当初は新聞系アプリケーションの担当 • 途中からウェブ系、電子版創刊時から関わる

   • いまは日経電子版の基盤系 インフラ担当（AWSも自社DCも両方） • 兵庫県神戸市出身 • 好きなAWSサービス 修行中でまだありません 2
3. 3.

   きょうお話する内容 • オンプレミスからAWSにシステム移行する話 • AWSに構築したシステムの概要 • AWSに移行するにあたり – 注力した点 –

   苦労した点 3
4. 4.

   日経電子版の紹介 4 Android & iPhone モバイル ＰＣ 新聞 電子版 マーケット

   携帯 Windows8 Android & iPad iPhone
5. 5.

   日経電子版の紹介 • ２０１０年 日経電子版創刊 – １９９６年から日経ネット • ４０万人を超える有料会員 • ２５０万人を超える登録会員

   • 有料ニュースサービス • iPhone/Androidのモバイルサービス強化 • エバーノートとの連携 • サービス系開発部隊は４０人程度 5
6. 6.

   メディアとして • 必ず最新の情報がいち早く届く • いつでもどこでも、持ち歩いて読める • マルチデバイスに対応 • コンテンツ更新を即反映 •

   応答が速い • 対障害性が高い 6
7. 7.

   日経電子版システム的な特徴 • ピークとオフピークのトラフィック比１０倍近く • 営業日と非営業日のトラフィックの差も大きい • 重大ニュース発生時など、突発的アクセス増 • 想定ピークに合わせシステムリソースをオンプレで用意 •

   コンテンツの応答性能にこだわってきた – コンテンツ配信できめ細かいキャッシュ制御 • サービス開発は常に継続、ほぼ毎週リリース 7
8. 8.

   電子版へのアクセス傾向（平日） • AM9時、12時、15時にアクセスピーク 8

9. 9.

   いままでのAWSの活用、関わり • 新サービス投入のタイミングでそのコンテンツ配 信基盤として構築してきた – 電子版モバイル(2013/春) – NIKKEI ASIAN REVIEW

   (2013/秋) – Niid（2014/秋) – 技術的な観点で経験を重ねてきた • E-JAWS • re:Invent2014に参加 9
10. 10.

    なぜAWSか • 日経電子版を支える柔軟なシステム基盤 • 突発的なアクセスピークに耐える強力な基盤 • 状況に合わせて進化できる基盤 • オンプレはハード更新毎に人的リソースが割かれる •

    サービス開発に注力 • 自分たちで設計・運営できる基盤 – ブラックボックス化したくない – 少人数のインフラチーム運営 10
11. 11.

    自社データセンターからの移行は初 • ハードウェアの更改のタイミングでクラウド化 • AWSをさらに活用 – 地ならしは徐々にできてきた – 移行のノウハウはなかった •

    クラウドパックさんとの出会い – クラウドAWSの使いこなし方、ノウハウ – AWSのお作法に従って構築 11
12. 12.

    クラウド移行の方針・考え方 • アプリケーションのレイヤーは変更せず基盤 部分の変更に集中 • サービスを止めることなく、より安全にスムー ズに切り替える 12

13. 13.

    移行に関する数字 13 自社DC AWS 台数 合計160台 合計270台 応答時間 （キャッシュサーバログより ）

    無料会員=約50%向上 有料会員=約40%向上 移植したロードバランサー⾏数 11500⾏ 移植したバッチジョブの本数 760本 Backlogの課題件数 2500件 テストケース数 3000件 移⾏リハーサル ５回
14. 14.

    AWSでのシステム構築概要 14 AWS 基盤 （AWS全体設計、サーバ設計、インストール、監視、ウィルス対策、 パッチ、構成管理、ログ解析、監視メッセージ送信、自動テスト） 記事系アプ リケーショ ン、記事API 基

    盤 HA proxy varni sh HA proxy ELB 数値系アプ リケーショ ン、数値API
15. 15.

    フロント部分のシステム構成 • ELBにL7レベルのアクセス振り分け機能がなかった ため自社DCで使っていたロードバランサー（約１万 行）の機能をHAProxyに移植した • 有料会員向けリソースと無料会員向けリソースを分 ける振り分け条件 • 配下のELB数

    約30個 15
16. 16.

    記事系アプ リケーショ ン、記事API 有料用サーバ 無料用サーバ アクセスの振り分けとAPI 16 AWS 基盤 （AWS全体設計、サーバ設計、インストール、監視、ウィルス対策、

    パッチ、構成管理、ログ解析、監視メッセージ送信、自動テスト） 基 盤 HA proxy varni sh HA proxy ELB 数値系アプ リケーショ ン、数値API 有料用サーバ 無料用サーバ
17. 17.

    オンプレ時代の課題解決 • アクセスとリソースの可視化 – リバースプロキシのアクセスログ可視化 – リソース監視 • サーバ設定をエクセルではなくAnsibleで管理 –

    創刊前に構築した時のエクセルは使いものにならない状態だった • サーバの夜間・休日停止 • サーバ構築リードタイム大幅に短縮 • 専用線 – 自社DCとAWS間のインターネット通信障害 17
18. 18.

    オンプレミスからの移行のポイント • 電子版ユーザーに影響与えない – 記事が閲覧できる、ログインできる • 自社DCの他システムとの連携方式は維持 • 他サービスからのAPI連携方式は維持 •

    DCのインターネットトラフィックがAWSに移動 • DNS変更が反映されない場合も考慮 • 移行するドメインが多数 18
19. 19.

    移行当日アクセスの切り替え • 深夜から約10時間の作業の中で引っ越す計画 – 最初にデータ移行 – 次にアクセスの切り替え（２段階） • 自社DCとAWSの両方にアクセスがいく時間をなく す

    – 両拠点でセッション情報持てない • 自社DCに入ってきたアクセスをAWS側に回すこ とで、サービスを途切れさせない 19
20. 20.

    自社DC Step1:自社DCに入ってきたアクセスを回す 20 AWS ELB 専用線 www.nikkei.com

21. 21.

    自社DC Step2:DNS切り替え 21 AWS ELB 専用線 www.nikkei.com

22. 22.

    ここまでやる理由 • システム移行時にサービスを途切れさせない • 単純にDNSを切り替えるというだけでは満たせな い – DNS変更の伝搬時間に依存しない – Step1でNGの場合は切り戻せる

    • 社内・他システムの連携先が１０個以上で多い ため – コンテンツを提供するAPI群 22
23. 23.

    苦労した点（その１） • クラスタソフト – 書き込みが発生する箇所に配置 • NFSサーバ（共有ファイルサーバ） • セッション管理サーバ –

    専用線経由で代表アドレス通信はできない • オンプレ側アプリケーションの変更を余儀なくされた – はやくマネージドのAmazon EFSを利用したい 23
24. 24.

    苦労した点（その２） • オンプレのロードバランサー移植 – ELBで足りない機能、L7レベル振り分けをHAProxyで実装 – アクセス制限 • 専用線経由の通信 –

    マネージドのIPアドレスは可変 • DC側からElastiCacheに対して専用線経由でアクセス • 自社DCとAWSのアドレス体系 NATを使う – 専用線でELBにアクセスできないのはあきらめた 24
25. 25.

    テストで注力した点 • 自社DCからのデータ・ファイル転送 – データベースレプリケーション • MSSQL – 紙面イメージのサービスで使う画像データ転送 •

    10分間で6000ファイル – 40万人の会員向けメール処理 • 朝刊と夕刊の2回、登録したキーワードに関するメール本文作成処理 • 移行前より時間的に遅延するのは許されない • アクセス性能テスト • アベイラビリティゾーンのA系とC系をまたぐ通信（約2ms） 25
26. 26.

    AWSに移行してよかったこと • 応答性能の向上 • スペックや台数を柔軟にコントロール • ネットワークやサーバ構築の基盤系作業のリー ドタイム短縮 – 新規・連携サービスの短期リリースに寄与

    • リリース作業の時間短縮 – アプリケーション開発に寄与 26
27. 27.

    クラウドで良かった点 • 性能テスト – ボトルネックを探す – ピーク性能を測る • サイジングに時間を取られなかった •

    ピークに備えて台数確保 • テスト環境の構築のしやすさ（Route53活用） – 自社環境のwww.nikkei.comと同じものをAWS側にも作れた • とは言え、まだ「道半ば」 27
28. 28.

    使ってみて課題・トラブル • 支払い費用 – コスト削減 • さらなる自動化 • AWS内部のネットワークトラブル –

    パケットロスにより、紙面データの送信失敗 • クラスタソフトが動かない – サービスが不安定になり紙面データ送信失敗 28
29. 29.

    今後もアーキテクチャ見直しで進化 • ファイル共有の仕組みを変えていく – 今はクラスタのNFSサーバ – S3活用 – Amazon EFSの活用

    • データベースをマネージドに – 今はEC2上に構築 • Windowsのサーバを減らしていく 29
30. 30.

    まとめ • 今回の構成、構築とオンプレからの改善点 • オンプレからAWSへ移行方式やポイント • AWSを移行してみてよかった点 • 日経電子版のシステム基盤のこれから 30

31. 31.

    最後に • インフラ基盤を自分たちで設計・運営していく • よりモダンなインフラ基盤に進化させ、サービ ス開発、事業へ貢献 31

32. 32.

    技術チームとしての活動 • アプリケーション系 – 「アプリケーション開発の内製化」など勉強会 • インフラ系 – 「Ansible Meetup」など勉強会

    – 今夜「ログ分析勉強会 vol.1」 「Kibana4で秒間1万件のアクセスログを可視化した話」 http://loganalytics.connpass.com/event/19614/ 32 @bungoume
33. 33.

    33

34. 34.

    技術者募集 • 電子版のサービスやアプリケーション、システ ムを支える仲間を募集しています • ご興味がある方は以下のアドレスにご連絡く ださい dg_lab@nex.nikkei.co.jp 34

35. 35.

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