日経電子版のAWS移行

AWSクラウドへの移行プロジェクトについて

Transcript

1. 日経電子版のAWS移行 日本経済新聞社 デジタル編成局 西馬一郎 2015/10/15 Cloudpack User Group MeetUp 2015
2. 自己紹介 • 西馬一郎（ニシウマ イチロウ） • 2002年入社 • 当初は新聞系アプリケーションの担当 • 途中からウェブ系、電子版創刊時から関わる • いまは日経電子版の基盤系 インフラ担当（AWSも自社DCも両方） • 兵庫県神戸市出身 • 好きなAWSサービス 修行中でまだありません 2
3. きょうお話する内容 • オンプレミスからAWSにシステム移行する話 • AWSに構築したシステムの概要 • AWSに移行するにあたり – 注力した点 – 苦労した点 3
4. 日経電子版の紹介 4 Android & iPhone モバイル ＰＣ 新聞 電子版 マーケット 携帯 Windows8 Android & iPad iPhone
5. 日経電子版の紹介 • ２０１０年 日経電子版創刊 – １９９６年から日経ネット • ４０万人を超える有料会員 • ２５０万人を超える登録会員 • 有料ニュースサービス • iPhone/Androidのモバイルサービス強化 • エバーノートとの連携 • サービス系開発部隊は４０人程度 5
6. メディアとして • 必ず最新の情報がいち早く届く • いつでもどこでも、持ち歩いて読める • マルチデバイスに対応 • コンテンツ更新を即反映 • 応答が速い • 対障害性が高い 6
7. 日経電子版システム的な特徴 • ピークとオフピークのトラフィック比１０倍近く • 営業日と非営業日のトラフィックの差も大きい • 重大ニュース発生時など、突発的アクセス増 • 想定ピークに合わせシステムリソースをオンプレで用意 • コンテンツの応答性能にこだわってきた – コンテンツ配信できめ細かいキャッシュ制御 • サービス開発は常に継続、ほぼ毎週リリース 7
8. 電子版へのアクセス傾向（平日） • AM9時、12時、15時にアクセスピーク 8
9. いままでのAWSの活用、関わり • 新サービス投入のタイミングでそのコンテンツ配 信基盤として構築してきた – 電子版モバイル(2013/春) – NIKKEI ASIAN REVIEW (2013/秋) – Niid（2014/秋) – 技術的な観点で経験を重ねてきた • E-JAWS • re:Invent2014に参加 9
10. なぜAWSか • 日経電子版を支える柔軟なシステム基盤 • 突発的なアクセスピークに耐える強力な基盤 • 状況に合わせて進化できる基盤 • オンプレはハード更新毎に人的リソースが割かれる • サービス開発に注力 • 自分たちで設計・運営できる基盤 – ブラックボックス化したくない – 少人数のインフラチーム運営 10
11. 自社データセンターからの移行は初 • ハードウェアの更改のタイミングでクラウド化 • AWSをさらに活用 – 地ならしは徐々にできてきた – 移行のノウハウはなかった • クラウドパックさんとの出会い – クラウドAWSの使いこなし方、ノウハウ – AWSのお作法に従って構築 11
12. クラウド移行の方針・考え方 • アプリケーションのレイヤーは変更せず基盤 部分の変更に集中 • サービスを止めることなく、より安全にスムー ズに切り替える 12
13. 移行に関する数字 13 自社DC AWS 台数 合計160台 合計270台 応答時間 （キャッシュサーバログより ） 無料会員=約50%向上 有料会員=約40%向上 移植したロードバランサー⾏数 11500⾏ 移植したバッチジョブの本数 760本 Backlogの課題件数 2500件 テストケース数 3000件 移⾏リハーサル ５回
14. AWSでのシステム構築概要 14 AWS 基盤 （AWS全体設計、サーバ設計、インストール、監視、ウィルス対策、 パッチ、構成管理、ログ解析、監視メッセージ送信、自動テスト） 記事系アプ リケーショ ン、記事API 基 盤 HA proxy varni sh HA proxy ELB 数値系アプ リケーショ ン、数値API
15. フロント部分のシステム構成 • ELBにL7レベルのアクセス振り分け機能がなかった ため自社DCで使っていたロードバランサー（約１万 行）の機能をHAProxyに移植した • 有料会員向けリソースと無料会員向けリソースを分 ける振り分け条件 • 配下のELB数 約30個 15
16. 記事系アプ リケーショ ン、記事API 有料用サーバ 無料用サーバ アクセスの振り分けとAPI 16 AWS 基盤 （AWS全体設計、サーバ設計、インストール、監視、ウィルス対策、 パッチ、構成管理、ログ解析、監視メッセージ送信、自動テスト） 基 盤 HA proxy varni sh HA proxy ELB 数値系アプ リケーショ ン、数値API 有料用サーバ 無料用サーバ
17. オンプレ時代の課題解決 • アクセスとリソースの可視化 – リバースプロキシのアクセスログ可視化 – リソース監視 • サーバ設定をエクセルではなくAnsibleで管理 – 創刊前に構築した時のエクセルは使いものにならない状態だった • サーバの夜間・休日停止 • サーバ構築リードタイム大幅に短縮 • 専用線 – 自社DCとAWS間のインターネット通信障害 17
18. オンプレミスからの移行のポイント • 電子版ユーザーに影響与えない – 記事が閲覧できる、ログインできる • 自社DCの他システムとの連携方式は維持 • 他サービスからのAPI連携方式は維持 • DCのインターネットトラフィックがAWSに移動 • DNS変更が反映されない場合も考慮 • 移行するドメインが多数 18
19. 移行当日アクセスの切り替え • 深夜から約10時間の作業の中で引っ越す計画 – 最初にデータ移行 – 次にアクセスの切り替え（２段階） • 自社DCとAWSの両方にアクセスがいく時間をなく す – 両拠点でセッション情報持てない • 自社DCに入ってきたアクセスをAWS側に回すこ とで、サービスを途切れさせない 19
20. 自社DC Step1:自社DCに入ってきたアクセスを回す 20 AWS ELB 専用線 www.nikkei.com
21. 自社DC Step2:DNS切り替え 21 AWS ELB 専用線 www.nikkei.com
22. ここまでやる理由 • システム移行時にサービスを途切れさせない • 単純にDNSを切り替えるというだけでは満たせな い – DNS変更の伝搬時間に依存しない – Step1でNGの場合は切り戻せる • 社内・他システムの連携先が１０個以上で多い ため – コンテンツを提供するAPI群 22
23. 苦労した点（その１） • クラスタソフト – 書き込みが発生する箇所に配置 • NFSサーバ（共有ファイルサーバ） • セッション管理サーバ – 専用線経由で代表アドレス通信はできない • オンプレ側アプリケーションの変更を余儀なくされた – はやくマネージドのAmazon EFSを利用したい 23
24. 苦労した点（その２） • オンプレのロードバランサー移植 – ELBで足りない機能、L7レベル振り分けをHAProxyで実装 – アクセス制限 • 専用線経由の通信 – マネージドのIPアドレスは可変 • DC側からElastiCacheに対して専用線経由でアクセス • 自社DCとAWSのアドレス体系 NATを使う – 専用線でELBにアクセスできないのはあきらめた 24
25. テストで注力した点 • 自社DCからのデータ・ファイル転送 – データベースレプリケーション • MSSQL – 紙面イメージのサービスで使う画像データ転送 • 10分間で6000ファイル – 40万人の会員向けメール処理 • 朝刊と夕刊の2回、登録したキーワードに関するメール本文作成処理 • 移行前より時間的に遅延するのは許されない • アクセス性能テスト • アベイラビリティゾーンのA系とC系をまたぐ通信（約2ms） 25
26. AWSに移行してよかったこと • 応答性能の向上 • スペックや台数を柔軟にコントロール • ネットワークやサーバ構築の基盤系作業のリー ドタイム短縮 – 新規・連携サービスの短期リリースに寄与 • リリース作業の時間短縮 – アプリケーション開発に寄与 26
27. クラウドで良かった点 • 性能テスト – ボトルネックを探す – ピーク性能を測る • サイジングに時間を取られなかった • ピークに備えて台数確保 • テスト環境の構築のしやすさ（Route53活用） – 自社環境のwww.nikkei.comと同じものをAWS側にも作れた • とは言え、まだ「道半ば」 27
28. 使ってみて課題・トラブル • 支払い費用 – コスト削減 • さらなる自動化 • AWS内部のネットワークトラブル – パケットロスにより、紙面データの送信失敗 • クラスタソフトが動かない – サービスが不安定になり紙面データ送信失敗 28
29. 今後もアーキテクチャ見直しで進化 • ファイル共有の仕組みを変えていく – 今はクラスタのNFSサーバ – S3活用 – Amazon EFSの活用 • データベースをマネージドに – 今はEC2上に構築 • Windowsのサーバを減らしていく 29
30. まとめ • 今回の構成、構築とオンプレからの改善点 • オンプレからAWSへ移行方式やポイント • AWSを移行してみてよかった点 • 日経電子版のシステム基盤のこれから 30
31. 最後に • インフラ基盤を自分たちで設計・運営していく • よりモダンなインフラ基盤に進化させ、サービ ス開発、事業へ貢献 31
32. 技術チームとしての活動 • アプリケーション系 – 「アプリケーション開発の内製化」など勉強会 • インフラ系 – 「Ansible Meetup」など勉強会 – 今夜「ログ分析勉強会 vol.1」 「Kibana4で秒間1万件のアクセスログを可視化した話」 http://loganalytics.connpass.com/event/19614/ 32 @bungoume
34. 技術者募集 • 電子版のサービスやアプリケーション、システ ムを支える仲間を募集しています • ご興味がある方は以下のアドレスにご連絡く ださい dg_lab@nex.nikkei.co.jp 34
35. ご清聴、ありがとうございました。 35