Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
日経電子版のAWS移行
Search
Ichiro Nishiuma
October 16, 2015
Technology
0
240
日経電子版のAWS移行
AWSクラウドへの移行プロジェクトについて
Ichiro Nishiuma
October 16, 2015
Tweet
Share
More Decks by Ichiro Nishiuma
See All by Ichiro Nishiuma
エンジニア採用から始まる技術広報と組織づくり/202506lt
nishiuma
8
2.1k
新卒エンジニア研修の試行錯誤と工夫/nikkei-tech-talk-31
nishiuma
0
580
エンジニア採用と 技術広報の実践/acaricsummit2025
nishiuma
1
270
2025年の挑戦 コーポレートエンジニアの技術広報/techpr5
nishiuma
0
320
社外コミュニティで学び社内に活かす共に学ぶプロジェクトの実践/backlogworld2024
nishiuma
0
440
社内の学びの場・コミュニティ形成とエンジニア同士のリレーションシップ構築/devreljapan2024
nishiuma
4
440
日経電子版から始まった内製開発の現在地と向き合っている課題/inhouse
nishiuma
0
570
エンジニア採用を起点に取り組む組織の改善活動と課題、中長期のタスク管理/ #HRmethod
nishiuma
4
4.1k
みんなで盛り上げ築くリレーション、日経の新卒エンジニア研修 #chiyoda_tech
nishiuma
1
360
Other Decks in Technology
See All in Technology
Claude Code に プロジェクト管理やらせたみた
unson
6
4.2k
united airlines ™®️ USA Contact Numbers: Complete 2025 Support Guide
flyunitedhelp
1
340
ゼロからはじめる採用広報
yutadayo
3
960
「クラウドコスト絶対削減」を支える技術—FinOpsを超えた徹底的なクラウドコスト削減の実践論
delta_tech
4
170
AI専用のリンターを作る #yumemi_patch
bengo4com
5
4.3k
american aa airlines®️ USA Contact Numbers: Complete 2025 Support Guide
aaguide
0
230
B2C&B2B&社内向けサービスを抱える開発組織におけるサービス価値を最大化するイニシアチブ管理
belongadmin
2
7.1k
面倒な作業はAIにおまかせ。Flutter開発をスマートに効率化
ruideengineer
0
260
United Airlines Customer Service– Call 1-833-341-3142 Now!
airhelp
0
170
20250705 Headlamp: 專注可擴展性的 Kubernetes 用戶界面
pichuang
0
270
LangChain Interrupt & LangChain Ambassadors meetingレポート
os1ma
2
320
american airlines®️ USA Contact Numbers: Complete 2025 Support Guide
supportflight
1
110
Featured
See All Featured
Designing for humans not robots
tammielis
253
25k
Reflections from 52 weeks, 52 projects
jeffersonlam
351
20k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
281
13k
Become a Pro
speakerdeck
PRO
29
5.4k
The Art of Programming - Codeland 2020
erikaheidi
54
13k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
161
15k
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
7
740
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
50
5.5k
Build The Right Thing And Hit Your Dates
maggiecrowley
36
2.8k
Optimising Largest Contentful Paint
csswizardry
37
3.3k
GitHub's CSS Performance
jonrohan
1031
460k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
3.9k
Transcript
日経電子版のAWS移行 日本経済新聞社 デジタル編成局 西馬一郎 2015/10/15 Cloudpack User Group MeetUp 2015
自己紹介 • 西馬一郎(ニシウマ イチロウ) • 2002年入社 • 当初は新聞系アプリケーションの担当 • 途中からウェブ系、電子版創刊時から関わる
• いまは日経電子版の基盤系 インフラ担当(AWSも自社DCも両方) • 兵庫県神戸市出身 • 好きなAWSサービス 修行中でまだありません 2
きょうお話する内容 • オンプレミスからAWSにシステム移行する話 • AWSに構築したシステムの概要 • AWSに移行するにあたり – 注力した点 –
苦労した点 3
日経電子版の紹介 4 Android & iPhone モバイル PC 新聞 電子版 マーケット
携帯 Windows8 Android & iPad iPhone
日経電子版の紹介 • 2010年 日経電子版創刊 – 1996年から日経ネット • 40万人を超える有料会員 • 250万人を超える登録会員
• 有料ニュースサービス • iPhone/Androidのモバイルサービス強化 • エバーノートとの連携 • サービス系開発部隊は40人程度 5
メディアとして • 必ず最新の情報がいち早く届く • いつでもどこでも、持ち歩いて読める • マルチデバイスに対応 • コンテンツ更新を即反映 •
応答が速い • 対障害性が高い 6
日経電子版システム的な特徴 • ピークとオフピークのトラフィック比10倍近く • 営業日と非営業日のトラフィックの差も大きい • 重大ニュース発生時など、突発的アクセス増 • 想定ピークに合わせシステムリソースをオンプレで用意 •
コンテンツの応答性能にこだわってきた – コンテンツ配信できめ細かいキャッシュ制御 • サービス開発は常に継続、ほぼ毎週リリース 7
電子版へのアクセス傾向(平日) • AM9時、12時、15時にアクセスピーク 8
いままでのAWSの活用、関わり • 新サービス投入のタイミングでそのコンテンツ配 信基盤として構築してきた – 電子版モバイル(2013/春) – NIKKEI ASIAN REVIEW
(2013/秋) – Niid(2014/秋) – 技術的な観点で経験を重ねてきた • E-JAWS • re:Invent2014に参加 9
なぜAWSか • 日経電子版を支える柔軟なシステム基盤 • 突発的なアクセスピークに耐える強力な基盤 • 状況に合わせて進化できる基盤 • オンプレはハード更新毎に人的リソースが割かれる •
サービス開発に注力 • 自分たちで設計・運営できる基盤 – ブラックボックス化したくない – 少人数のインフラチーム運営 10
自社データセンターからの移行は初 • ハードウェアの更改のタイミングでクラウド化 • AWSをさらに活用 – 地ならしは徐々にできてきた – 移行のノウハウはなかった •
クラウドパックさんとの出会い – クラウドAWSの使いこなし方、ノウハウ – AWSのお作法に従って構築 11
クラウド移行の方針・考え方 • アプリケーションのレイヤーは変更せず基盤 部分の変更に集中 • サービスを止めることなく、より安全にスムー ズに切り替える 12
移行に関する数字 13 自社DC AWS 台数 合計160台 合計270台 応答時間 (キャッシュサーバログより )
無料会員=約50%向上 有料会員=約40%向上 移植したロードバランサー⾏数 11500⾏ 移植したバッチジョブの本数 760本 Backlogの課題件数 2500件 テストケース数 3000件 移⾏リハーサル 5回
AWSでのシステム構築概要 14 AWS 基盤 (AWS全体設計、サーバ設計、インストール、監視、ウィルス対策、 パッチ、構成管理、ログ解析、監視メッセージ送信、自動テスト) 記事系アプ リケーショ ン、記事API 基
盤 HA proxy varni sh HA proxy ELB 数値系アプ リケーショ ン、数値API
フロント部分のシステム構成 • ELBにL7レベルのアクセス振り分け機能がなかった ため自社DCで使っていたロードバランサー(約1万 行)の機能をHAProxyに移植した • 有料会員向けリソースと無料会員向けリソースを分 ける振り分け条件 • 配下のELB数
約30個 15
記事系アプ リケーショ ン、記事API 有料用サーバ 無料用サーバ アクセスの振り分けとAPI 16 AWS 基盤 (AWS全体設計、サーバ設計、インストール、監視、ウィルス対策、
パッチ、構成管理、ログ解析、監視メッセージ送信、自動テスト) 基 盤 HA proxy varni sh HA proxy ELB 数値系アプ リケーショ ン、数値API 有料用サーバ 無料用サーバ
オンプレ時代の課題解決 • アクセスとリソースの可視化 – リバースプロキシのアクセスログ可視化 – リソース監視 • サーバ設定をエクセルではなくAnsibleで管理 –
創刊前に構築した時のエクセルは使いものにならない状態だった • サーバの夜間・休日停止 • サーバ構築リードタイム大幅に短縮 • 専用線 – 自社DCとAWS間のインターネット通信障害 17
オンプレミスからの移行のポイント • 電子版ユーザーに影響与えない – 記事が閲覧できる、ログインできる • 自社DCの他システムとの連携方式は維持 • 他サービスからのAPI連携方式は維持 •
DCのインターネットトラフィックがAWSに移動 • DNS変更が反映されない場合も考慮 • 移行するドメインが多数 18
移行当日アクセスの切り替え • 深夜から約10時間の作業の中で引っ越す計画 – 最初にデータ移行 – 次にアクセスの切り替え(2段階) • 自社DCとAWSの両方にアクセスがいく時間をなく す
– 両拠点でセッション情報持てない • 自社DCに入ってきたアクセスをAWS側に回すこ とで、サービスを途切れさせない 19
自社DC Step1:自社DCに入ってきたアクセスを回す 20 AWS ELB 専用線 www.nikkei.com
自社DC Step2:DNS切り替え 21 AWS ELB 専用線 www.nikkei.com
ここまでやる理由 • システム移行時にサービスを途切れさせない • 単純にDNSを切り替えるというだけでは満たせな い – DNS変更の伝搬時間に依存しない – Step1でNGの場合は切り戻せる
• 社内・他システムの連携先が10個以上で多い ため – コンテンツを提供するAPI群 22
苦労した点(その1) • クラスタソフト – 書き込みが発生する箇所に配置 • NFSサーバ(共有ファイルサーバ) • セッション管理サーバ –
専用線経由で代表アドレス通信はできない • オンプレ側アプリケーションの変更を余儀なくされた – はやくマネージドのAmazon EFSを利用したい 23
苦労した点(その2) • オンプレのロードバランサー移植 – ELBで足りない機能、L7レベル振り分けをHAProxyで実装 – アクセス制限 • 専用線経由の通信 –
マネージドのIPアドレスは可変 • DC側からElastiCacheに対して専用線経由でアクセス • 自社DCとAWSのアドレス体系 NATを使う – 専用線でELBにアクセスできないのはあきらめた 24
テストで注力した点 • 自社DCからのデータ・ファイル転送 – データベースレプリケーション • MSSQL – 紙面イメージのサービスで使う画像データ転送 •
10分間で6000ファイル – 40万人の会員向けメール処理 • 朝刊と夕刊の2回、登録したキーワードに関するメール本文作成処理 • 移行前より時間的に遅延するのは許されない • アクセス性能テスト • アベイラビリティゾーンのA系とC系をまたぐ通信(約2ms) 25
AWSに移行してよかったこと • 応答性能の向上 • スペックや台数を柔軟にコントロール • ネットワークやサーバ構築の基盤系作業のリー ドタイム短縮 – 新規・連携サービスの短期リリースに寄与
• リリース作業の時間短縮 – アプリケーション開発に寄与 26
クラウドで良かった点 • 性能テスト – ボトルネックを探す – ピーク性能を測る • サイジングに時間を取られなかった •
ピークに備えて台数確保 • テスト環境の構築のしやすさ(Route53活用) – 自社環境のwww.nikkei.comと同じものをAWS側にも作れた • とは言え、まだ「道半ば」 27
使ってみて課題・トラブル • 支払い費用 – コスト削減 • さらなる自動化 • AWS内部のネットワークトラブル –
パケットロスにより、紙面データの送信失敗 • クラスタソフトが動かない – サービスが不安定になり紙面データ送信失敗 28
今後もアーキテクチャ見直しで進化 • ファイル共有の仕組みを変えていく – 今はクラスタのNFSサーバ – S3活用 – Amazon EFSの活用
• データベースをマネージドに – 今はEC2上に構築 • Windowsのサーバを減らしていく 29
まとめ • 今回の構成、構築とオンプレからの改善点 • オンプレからAWSへ移行方式やポイント • AWSを移行してみてよかった点 • 日経電子版のシステム基盤のこれから 30
最後に • インフラ基盤を自分たちで設計・運営していく • よりモダンなインフラ基盤に進化させ、サービ ス開発、事業へ貢献 31
技術チームとしての活動 • アプリケーション系 – 「アプリケーション開発の内製化」など勉強会 • インフラ系 – 「Ansible Meetup」など勉強会
– 今夜「ログ分析勉強会 vol.1」 「Kibana4で秒間1万件のアクセスログを可視化した話」 http://loganalytics.connpass.com/event/19614/ 32 @bungoume
33
技術者募集 • 電子版のサービスやアプリケーション、システ ムを支える仲間を募集しています • ご興味がある方は以下のアドレスにご連絡く ださい
[email protected]
34
ご清聴、ありがとうございました。 35