25.3K Views
November 09, 22
スライド概要
AWS Dev Day 2022 Japanで発表した資料です
経済ニュースアプリのSREの仕事をしています。
NewsPicksの「最高の開発者体験」への挑戦 〜Amazon ECSによる全面コンテナ化の軌跡〜 株式会社ニューズピックス 安藤 裕紀, Edwin Wilson AWS Dev Day 2022 Japan - 2022.11.09(Wed)
00 自己紹介 安藤 裕紀 / Yuki Ando Edwin Wilson NewsPicks.Inc SRE Unit NewsPicks.Inc SRE Unit SREチームのプレイングマネージャー SREチームテックリード ©NewsPicks Inc. All Rights Reserved.
00 目次 1. NewsPicksとSREチームについて 2. NewsPicksが抱えていた課題 3. 全面コンテナ化への挑戦 4. コンテナ化の成果とまとめ ©NewsPicks Inc. All Rights Reserved.
01 NewsPicksとSREチームについて ©NewsPicks Inc. All Rights Reserved.
01 ソーシャル経済メディア NewsPicksについて タイトルタイトルタイトルタイトルタイトルタイトルタイト ルタイトルタイトルタイトル テキストテキストテキストテキストテキストテキストテ キストテキストテキストテキストテキストテキストテキ ストテキストテキストテキストテキストテキストテキスト テキストテキストテキストテキストテキストテキストテ キストテキストテキストテキストテキストテキストテキ ストテキストテキストテキストテキストテキストテキスト テキストテキストテキストテキストテキストテキストテ キストテキスト ©NewsPicks Inc. All Rights Reserved.
01 サービスのユーザー数・プレミアム会員ともに成長中 ©NewsPicks Inc. All Rights Reserved.
01 NewsPicksはエンジニアの開発者体験を重要視しています NewsPicksエンジニア向け採用サイト※1の 「働く環境/福利厚生」の1stビューに 「最高の開発者体験の追求」を掲げています 「Findy Team+ Award 2022」において、 NewsPicksが「エンジニア組織の生産性指標が高い 企業」として選出されました※2 ※1 https://tech.newspicks.com/ ※2 https://tech.uzabase.com/entry/2022/10/25/151838 ©NewsPicks Inc. All Rights Reserved.
01 プロダクト開発組織のSREは1チームで複数事業のインフラを担当 SRE ©NewsPicks Inc. All Rights Reserved.
01 SREチームのミッションと、活動の4つの軸 Mission 誰もが安全かつ高速に開発できるインフラを提供することで、 NewsPicksの企業価値を継続的に向上させる ユーザー体験を守る 開発者体験を高める 常にユーザー視点のモニタリングを行い、可用性やレイテ ンシーのSLO達成を通じて快適なユーザー体験を提供する メディアとしてニュースのスパイクアクセスを難なく捌く ユーザーに価値を届けるプロダクト開発のパフォーマンスを 最大化するため、開発者の負を取り除き快適・安全・高速に 使える開発基盤サービスを提供する レガシーを捨てる セキュリティ・コストを適正化する レガシーなサーバーOSやミドルウェア、言語ランタイム、 アーキテクチャーを継続的に刷新していく モダンな技術スタックによりエンジニア採用の競争力を 高め、プロダクト開発組織の成長阻害要因を取り除く SNSの側面があるソーシャル経済メディアをユーザーが安心し て利用できるセキュリティを確保する サービスの規模拡大に比例してサーバーのコストが増えない ようにし、売上に対するコストの割合を低くする ©NewsPicks Inc. All Rights Reserved.
01 本日の発表と、ミッションの関連 Mission 誰もが安全かつ高速に開発できるインフラを提供することで、 NewsPicksの企業価値を継続的に向上させる ユーザー体験を守る 開発者体験を高める 常にユーザー視点のモニタリングを行い、可用性やレイテ ンシーのSLO達成を通じて快適なユーザー体験を提供する メディアとしてニュースのスパイクアクセスを難なく捌く ユーザーに価値を届けるプロダクト開発のパフォーマンスを 最大化するため、開発者の負を取り除き快適・安全・高速に 使える開発基盤サービスを提供する レガシーを捨てる セキュリティ・コストを適正化する レガシーなサーバーOSやミドルウェア、言語ランタイム、 アーキテクチャーを継続的に刷新していく モダンな技術スタックによりエンジニア採用の競争力を 高め、プロダクト開発組織の成長阻害要因を取り除く SNSの側面があるソーシャル経済メディアをユーザーが安心 して利用できるセキュリティを確保する サービスの規模拡大に比例してサーバーのコストが増えない ようにし、売上に対するコストの割合を低くする ©NewsPicks Inc. All Rights Reserved.
01 開発者への支援を通じて最終的にユーザーに還元される価値を向上 コスト削減 サービス 事業 開発者体験 機能 開発者 ユーザー 機能・ユーザー体験 ユーザー体験(非機能)・セキュリティ ©NewsPicks Inc. All Rights Reserved. モダナイズ SRE
02 NewsPicksが抱えていた課題 ©NewsPicks Inc. All Rights Reserved.
02 ユーザーに価値を届けることを重視するNewsPicksの文化 開発者は、ユーザーに価値を届けるプロダクト開発に集中したい 開発者はフルサイクルを自走する過程でインフラの問題解決にもオーナーシップを持ちたい SREは、そんな開発者の体験を高める仕事に集中したい ©NewsPicks Inc. All Rights Reserved.
02 NewsPicksのシステムはかなり大規模かつレガシーでした システム概略図 AWS Cloud Application Integration, Management & Governance Analytics services EC2インスタンスが100台以上 SQS SNS Parameter Store Redshift Glue Data Pipeline EC2 instances スマホアプリ Auto Scaling group 社内システム Database services … … Aurora Web newspicsks-server DynamoDB ElastiCache Lambda functions ECS containers billing services … … search batch feed services … ©NewsPicks Inc. All Rights Reserved. ECR Storage S3 S3 Glacier
02 EC2でレガシーな運用を行っていたことによる課題 分類 課題 内容 開発者にとって インフラに関する認知負荷、 作業負荷 ● サーバーの構成を把握して、SSHして作業する必要がある ● ログの回収・調査など、複数台のサーバーから集めないといけない インフラの設定変更の リードタイム ● インフラの設定変更はSREチームに依頼が必要でリードタイムを要する 結果、プロダクト開発のリードタイムにオーナーシップを持ってユー ザーに価値を届けるということが難しくなる インフラの運用作業の工数 ● 設定のコード管理がされていないため、影響調査に時間がかかる ● AMIの作成と反映は作業の自動化がしづらく、手間がかかるので 作業が億劫になり、頻繁に実施できない ● 開発環境の増設が簡単にはできない。(subnetやSGの設定など…) ● EC2でプロビジョニングしているリソースに無駄があっても、プロセスごとのメモ リ使用率などがわからないので、削減余地が見えづらい ● EOLやAWSのメンテナンスなど、サービスや開発者の要件とは関係ない作業 にリソースがとられる セキュリティの問題 ● 脆弱性管理はGitHub Dependabotによるライブラリのみが対象 ● OS・ミドルウェアの定期的なバージョンアップがされていない SRE (インフラ担当) にとって ©NewsPicks Inc. All Rights Reserved.
02 コンテナ化して、プロダクト開発/運用のコア業務に集中したい 運用の責任範囲のコンテナ化によるBefore/After アプリケーション アプリケーション ライブラリ ライブラリ ミドルウェア ミドルウェア よりアプリケーションに近い 運用に集中 (コンテナランタイムや ログ管理・モニタリングに マネージドサービスを利用) コンテナ化 OS OS ハードウェア ハードウェア AWS利用者による運用 一部AWSによる運用 データセンター ©NewsPicks Inc. All Rights Reserved. データセンター AWSによる運用
02 Infrastructure as Codeによって誰でもインフラを触れるようにしたい AWS Cloud Development Kit (AWS CDK) AWS CDK(TypeScript)の採用 開発者がインフラを自分で開発して、プロダクト 開発に大きな裁量を持って自走できるようにする ために、NewsPicksではAWS CDKを全面採用 [AWS Black Belt Online Seminar] AWS Cloud Development Kit (CDK) https://d1.awsstatic.com/webinars/jp/pdf/services/2020 0303_BlackBelt_CDK.pdf ©NewsPicks Inc. All Rights Reserved. NewsPicksの開発者は普段からDynamoDBやSQS をアプリケーションから利用していて、AWSの SDKやサービスの開発知識を持っているので、 TerraformなどのDSLよりも、プログラミング言 語からSDKを使う感覚で利用できるCDK with TypeScriptの方が読みやすく書きやすいと判断
02 EC2インスタンスからコンテナ化することで、やりたいこと AWSのマネージドサービスを利用して、運用コストを削減できること ○ ログはサーバー外で一元管理・参照できる( CloudWatch Logs,S3) ○ EC2インスタンスのメンテナンスや EOLに対応する必要がなくなる ○ アプリケーションに必要な最低限のリソースで運用できるようになる ○ セキュリティ対応の範囲を限定し、バージョンアップも楽になる インフラの設定がすべてコードで管理できるようになること ○ インフラの影響調査が楽になり、変更反映のリードタイムが短くなる ○ 開発環境の増設など、開発者のニーズに合わせた横展開も容易になる ○ CI/CDやプッシュ通知の AutoScalingなどサービス運用に適した自動化ができる ○ 開発者もインフラにコントリビュートできるようになる ©NewsPicks Inc. All Rights Reserved.
02 もっとも多くの開発者が開発し、コードベースの大きい newspicks-serverとbatchを対象にコンテナ化 システム概略図 AWS Cloud Application Integration, Management & Governance SQS SNS Parameter Store Analytics services Redshift Glue Data Pipeline EC2 instances スマホアプリ Auto Scaling group … … Web 社内システム Database services Aurora DynamoDB ElastiCache コンテナ化 newspicsks-server Lambda functions ECS containers billing services … … search batch feed services … ©NewsPicks Inc. All Rights Reserved. ECR Storage S3 S3 Glacier
03 全面コンテナ化への挑戦 ©NewsPicks Inc. All Rights Reserved.
03 はじめに、移行の要件を確認した EC2インスタンスからコンテナ化へ移行するの要件 1. 新しいリソースを全てコードで管理すること 2. 極力ダウンタイムを発生させないこと 3. 問題が発生した時にすぐに切り戻しが出来るようにすること 4. コンテナ化によるパフォーマンスの劣化がないこと 5. EC2運用時代よりも移行後のAWSコストが大きく増えないこと ©NewsPicks Inc. All Rights Reserved.
03 移行要件①新しいリソースを全てコードで管理すること AWS CDK(TypeScript)で Infrastructure as Code(IaC)を実現 Constructという概念がありインフラの構成を部 品化して再利用できるので、 開発環境や開発者サービスを横展開しやすい TypeScriptの型を利用して単体テストも書けるの で、開発者体験と開発効率が良い ©NewsPicks Inc. All Rights Reserved.
03 移行要件②③はEC2/ECSの並行稼動によって実現することにした EC2インスタンスからコンテナ化へ移行するの要件 1. 新しいリソースを全てコードで管理すること 2. 極力ダウンタイムを発生させないこと 3. 問題が発生した時にすぐに切り戻しが出来るようにすること 4. コンテナ化によるパフォーマンスの劣化がないこと 5. EC2運用時代よりも移行後のAWSコストが大きく増えないこと ©NewsPicks Inc. All Rights Reserved.
03 EC2とECSの並行稼働前のサーバ構成 ©NewsPicks Inc. All Rights Reserved.
03 EC2とECSの並行稼働中のサーバ構成 ©NewsPicks Inc. All Rights Reserved.
03 EC2時代のビルド・デプロイパイプライン ビルド デプロイ ©NewsPicks Inc. All Rights Reserved.
03 EC2とECSの並行稼働中のビルドパイプライン EC2用のビルド成果物は そのまま コンテナイメージを作成し、 ECRへのdocker pushを追加 ©NewsPicks Inc. All Rights Reserved.
03 EC2とECSの並行稼働中のデプロイパイプライン ©NewsPicks Inc. All Rights Reserved.
03 EC2とECSの並行稼働中のデプロイパイプライン ℹCodeDeployではなくLambdaを使った理由 アプリケーションのデプロイとインフラの変更を独立して行えるようにす るために、デプロイ時にLambdaからタスク定義を動的に作成するよう にした。 (ビルド時にタスク定義を作成するとインフラの変更を反映するためにア プリケーションの再ビルドが必要になるため) ©NewsPicks Inc. All Rights Reserved. ECSのRegister Task Definition APIと UpdateService APIを Lambdaから実行するス テートを既存の StepFunctionsに追加
03 EC2とECSの並行稼働によって移行要件②③を実現した EC2とECSの並行稼働によって… ● CDKでインフラを定義していることで一つの値を変えて、トラフィックの分散の調整 が出来る ● NewsPicksのサービスを止めずに移行が出来る ● コンテナのインスタンスで何か問題が発生した場合はロードバランサーの設定変更 でサービスアウトが出来る ● 徐々にコンテナの比率を増やして行く事でリスク少なく移行が出来る ©NewsPicks Inc. All Rights Reserved.
03 移行要件④⑤は当初想定の構成から見直しを行って実現した EC2インスタンスからコンテナ化へ移行するの要件 1. 新しいリソースを全てコードで管理すること 2. 極力ダウンタイムを発生させないこと 3. 問題が発生した時にすぐに切り戻しが出来るようにすること 4. コンテナ化によるパフォーマンスの劣化がないこと 5. EC2運用時代よりも移行後のAWSコストが大きく増えないこと ©NewsPicks Inc. All Rights Reserved.
03 NewsPicksの場合、ECS Fargateを使ったらコストが上がりすぎた ECS on Fargateから ECS on EC2に変更 ● 最初は、マネージドサービスを優先して、EC2からECS Fargateに移行するつもりだった ● 自分でEC2インスタンスのプロビジョニングしたくないから ● 並行稼働中にECS Fargateでのパフォーマンスは足りてなくて、SLOを満たす為に必要なイ ンスタンス数が想定より多くなり、コストが大きく増える事に気づいた (Fargateは数世代前のCPUで動いており、コストパフォーマンスが悪い) ● ECS on EC2を使って、インスタンスタイプをEC2と同じc5にすることで同じコストでSLOを達 成出来ることになった。(後に、c6iにして性能向上した) ©NewsPicks Inc. All Rights Reserved.
03 最終的にECS on EC2を使うことにした ● アプリケーションが既にコンテナで動いているから、ECS FargateからECS on EC2に移行す るのはとてもスムーズだった。 ● ECS最適化AMIを指定しているだけなので、EC2インスタンスの管理を全然意識していない ©NewsPicks Inc. All Rights Reserved.
03 コンテナへの移行後のデプロイパイプライン ©NewsPicks Inc. All Rights Reserved.
03 アプリケーションサーバーの移行の後、バッチプロセスも移行した NewsPicksでのバッチプロセスは enqueue/dequeueで実装 アプリケーションサーバーがバッチ処理をSQSにenqueue し、バッチサーバーの複数のワーカープロセスが ReceiveMessageして、処理を行って、dequeueする ● ● ● ● ワーカーがバッチサーバーを共用しているのでワーカープロセスは非効率的に配置されて いる キューにメッセージが少なくても常に同じ数のワーカープロセスが 全インスタンスで動いている 例えば、メッセージが少なくて、インスタンス2のワーカー2を止めてもいいのに、インスタン ス2のワーカー1は必要あるので、インスタンス数を減らせない SQSのdequeue単位で整合性があるので、ワーカープロセスは中断しても問題ない ©NewsPicks Inc. All Rights Reserved.
03 Fargate Spotを利用して、コストパフォーマンスの改善ができた ● ● ● ワーカー単位でECSのサービス/タスクを実行することにした EC2と比較して、ワーカー毎にタスク数を決めることができるので、 無駄なコンピューティングリソースがなくなった 各ワーカーで、一つのタスクのみFargateで実行して、中断を許容する追加のタ スクはFargate Spotにする事でコストが減る(最大70%) ©NewsPicks Inc. All Rights Reserved.
04 コンテナ化の成果とまとめ ©NewsPicks Inc. All Rights Reserved.
03 諸々の課題の改善・解決 分類 課題 コンテナ化後 開発者にとって インフラに関する認知負荷、 作業負荷 ✅サービスの構成をAWSマネジメントコンソールで把握できるようになった ✅開発者はログ回収・調査のためにSSHしなくて良くなった。CloudWatch Logs でログ調査できるようになり、サーバーの構成を意識する必要がなくなった インフラの設定変更の リードタイム ✅インフラの設定変更がコード化されたので、開発者自身がリポジトリのコード を読んで、インフラ設定変更のPRが出せるようになった。開発者のプロダクト 開発の自走力が向上し、問題解決の幅が広がった インフラの運用作業の工数 ✅すべての設定がコード化されているため、サーバーに SSHして設定調査しなくても本番 環境の設定を信じられる。変更をする際の工数が大幅に減った ✅AMIの管理から開放されたので、nginxやfluentdなどミドルウェアの設定変更を気軽に できるようになった。開発者の要望に対応するリードタイムも短縮した ✅開発環境の増設が簡単にできるようになり、開発規模の変化に柔軟になった ✅ECSタスク・コンテナ単位のリソースモニタリングができるようになり、リソース効率の最 適化・コスト削減の判断がしやすくなった ✅EC2インスタンスのEOLやAWSのメンテナンスなどにほぼ対応不要になった セキュリティの問題 ✅ECRの脆弱性スキャンにより、OSやミドルウェアに対しても継続的な脆弱性管理を行 えるようになった(運用面には課題があるため別製品を検討中) ✅ミドルウェアやライブラリのバージョンアップを実施する作業負荷が減った コードを修正しデプロイするだけなので、定期的に実施できるようになった SRE (インフラ担当) にとって ©NewsPicks Inc. All Rights Reserved.
03 開発者によるインフラへのコントリビュートが、次々と😊 SREチームへのCDK/インフラのPRレビュー依頼のSlack ©NewsPicks Inc. All Rights Reserved.
03 コンテナ化後のNewsPicks開発者の声🥰 CloudWatch Logsやコンテナ環境のリモートデバッグをできるようにした反応 ©NewsPicks Inc. All Rights Reserved.
04 ● まとめ よかったこと ○ コンテナ化・IaC化によって、SREチームの生産性や開発効率が上がり、 よりサービスやプロダクト開発のためになるテーマに注力できるようになった ○ 開発者自身でのインフラへのコントリビュートが容易になり、 「ユーザーのためにできることはなんでもやる」文化のNewsPicksで、 開発者がプロダクト開発のフルサイクルを自走して活躍できる幅が広がった ● 今後やっていきたいこと ○ インフラのモニタリング精度を上げてリソース効率とコストの最適化を進めたい(円安なので) ○ まだ他にEC2で動いているサービスをすべてコンテナ化・IaC化したい ○ より開発者体験を高めて、SLOモニタリングの啓蒙やセルフサービス化など 信頼性を高める活動への支援も提供していきたい ©NewsPicks Inc. All Rights Reserved.
ご清聴ありがとうございました! NewsPicksではエンジニアを積極採用中です! https://tech.newspicks.com ©NewsPicks Inc. All Rights Reserved.