10年モノのサービスのインフラを漸進的に改善する、頑張りすぎないクラウドネイティブ
34.1K Views
December 11, 23
スライド概要
CloudNative Days Tokyo 2023の発表資料です。
https://event.cloudnativedays.jp/cndt2023/talks/1967
経済ニュースアプリのSREの仕事をしています。
関連スライド
各ページのテキスト
10年モノのサービスのインフラを漸進的に改善する、 頑張りすぎないクラウドネイティブ 株式会社ユーザベース 安藤裕紀 CloudNative Days Tokyo 2023 - Track B 2023/12/11 17:20-18:00
00 自己紹介 安藤 裕紀(Yuki Ando) / あんどぅ NewsPicks事業 SRE Unit Leader 大手SIerで10年半エンジニア/アーキテクトとしてアプリケーション 開発、インフラ構築、クラウド活用コンサルティングなど大企業の 技術支援を行った後、2021年10月よりニューズピックス入社。 現在はSREチームのプレイングマネージャーとして、 サイトの信頼性と開発者体験の向上に取り組んでいます。 ©Uzabase, Inc. All Rights Reserved.
00 ソーシャル経済メディア NewsPicksについて ©Uzabase, Inc. All Rights Reserved.
00 今日話すこと 1. 10年モノのサービスのクラウド利用状況 2. バッチ周辺システムが10年前のままだった課題 3. 課題に対する ”頑張りすぎない” 改善策 3.1. バッチシステムのリプラットフォーム 3.2. プッシュ通知ChatOpsのリファクタリング 3.3. 踏み台サーバ・ツール実行サーバのリホスト 4. まとめ ©Uzabase, Inc. All Rights Reserved.
01 10年モノのサービスのクラウド利用状況 ©Uzabase, Inc. All Rights Reserved.
01 サービス開始当初からAWSを利用し10周年の節目を迎えました ©Uzabase, Inc. All Rights Reserved.
01 2年前までは、大半がEC2インスタンス中心のサービスでした システム概略図 (〜2021) AWS Cloud Application Integration, Management & Governance SQS SNS CloudWatch Parameter Store Analytics services Redshift Kinesis OpenSearch Data Streams Service EC2 instances スマホアプリ Auto Scaling group 社内・法人向けシステム Database services … … Aurora DynamoDB Web newspicsks-server RDS ECS containers ElastiCache Lambda functions feed services … … search batch billing services … ©Uzabase, Inc. All Rights Reserved. Storage S3 S3 Glacier
01 2年前までは、大半がEC2インスタンス中心のサービスでした システム概略図 (〜2021) AWS Cloud Application Integration, Management & Governance EC2インスタンスが100台以上 SQS SNS CloudWatch Parameter Store Analytics services Redshift Kinesis OpenSearch Data Streams Service EC2 instances スマホアプリ Auto Scaling group 社内・法人向けシステム Database services … … Aurora DynamoDB Web newspicsks-server RDS ECS containers ElastiCache Lambda functions feed services … … search batch billing services … ©Uzabase, Inc. All Rights Reserved. Storage S3 S3 Glacier
01 会場のみなさんが担当するサービスは？ 会場アンケート (挙手お願いします🙋) ● 担当するサービスでコンテナは利用していますか？ a. 大半がコンテナ or サーバーレス b. VMが半分以上です c. これからコンテナやサーバーレスやっていき CNCFの『The Cloud Native Trail Map』 によると コンテナ化とCI/CDはクラウドネイティブの第一歩だそうです。 ©Uzabase, Inc. All Rights Reserved.
01 NewsPicksは1年前にユーザー向けWeb/API周辺はコンテナ化が完了 システム概略図 (〜2022) AWS Cloud ECS containers Application Integration, Management & Governance Analytics services web services … bff services スマホアプリ … SQS SNS CloudWatch Parameter Store Redshift Kinesis OpenSearch Data Streams Service 社内・法人向けシステム Database services api services … Web … Aurora DynamoDB RDS xxx services … ECS containers ElastiCache Lambda functions feed services EC2 instances batch … billing services … ©Uzabase, Inc. All Rights Reserved. … Storage S3 S3 Glacier
01 コンテナ化とCI/CDの整備により開発者体験を向上できました AWS Dev Day 2022 Japanでの発表 CI/CD Conference 2023での発表 https://www.docswell.com/s/integrated1453/Z1LM2Z-newspickscontainerize-for-best-developer-experience https://www.docswell.com/s/integrated1453/5W1141-aws-cdkpipeline-kaizen ©Uzabase, Inc. All Rights Reserved.
01 一方、バッチ周辺システムは長らく手付かずでした システム概略図 (〜2022) AWS Cloud ECS containers Application Integration, Management & Governance Analytics services web services … bff services スマホアプリ … SQS SNS CloudWatch Parameter Store Redshift Kinesis OpenSearch Data Streams Service 社内・法人向けシステム Database services api services … Web … Aurora DynamoDB 10年前からほぼ変わっていなかった xxx services ECS containers バッチ周辺システムを今年いよいよ … なんとかした話をします feed services EC2 instances batch ElastiCache Lambda functions … … billing services … ©Uzabase, Inc. All Rights Reserved. RDS Storage S3 S3 Glacier
02 バッチ周辺システムが10年前のままだった課題 ©Uzabase, Inc. All Rights Reserved.
02 2023年も現役だったUbuntu 12.04のバッチサーバ😇 2012年4月にリリースされた「Ubuntu 12.04」のサポート期間は、 2017年4月28日に終了しています おそらく10年前から元気に『Welcome』と挨拶し続けてくれているUbuntu 12 ©Uzabase, Inc. All Rights Reserved.
02 バッチ周辺システムは、Ubuntu12.04のEC2インスタンス全10台 バッチ周辺システム （〜2022） 開発者 編成チーム AWS Cloud Virtual Private Cloud (VPC) bat000 SSH Slack Bastion (踏み台サーバ兼 ChatOpsサーバ) bat001,bat002 Amazon SQS bat101〜106 Queue ©Uzabase, Inc. All Rights Reserved.
02 バッチ周辺システムは、Ubuntu12.04のEC2インスタンス全10台 バッチ周辺システム （〜2022） 開発者 編成チーム SSH Slack AWS Cloud Virtual Private Cloud (VPC) 踏み台+ChatOps + 簡易cronタスク Bastion (踏み台サーバ兼 ChatOpsサーバ) bat000 bat001,bat002 常駐Worker処理 Amazon SQS bat101〜106 Queue ©Uzabase, Inc. All Rights Reserved. cron定時バッチ + 手動実行ツール
02 バッチ周辺システムは、Ubuntu12.04のEC2インスタンス全10台 バッチ周辺システム （〜2022） 開発者 編成チーム SSH Slack AWS Cloud 単なる踏み台以上の役割を持っている 重要なChatOpsの業務処理も中継しており Virtual Private Cloud (VPC) シェルスクリプトが20個くらいcronに登録 踏み台+ChatOps + 簡易cronタスク Bastion (踏み台サーバ兼 ChatOpsサーバ) bat000 bat001,bat002 常駐Worker処理 Amazon SQS bat101〜106 Queue ©Uzabase, Inc. All Rights Reserved. cron定時バッチ + 手動実行ツール
02 バッチ周辺システムは、Ubuntu12.04のEC2インスタンス全10台 バッチ周辺システム （〜2022） 開発者 編成チーム SSH Slack AWS Cloud cron定時バッチが30個くらい登録されてい る。管理画面化されていないエンジニア作業用 のツールをSSHして手動実行する場所でもある Virtual Private Cloud (VPC) 踏み台+ChatOps + 簡易cronタスク Bastion (踏み台サーバ兼 ChatOpsサーバ) bat000 bat001,bat002 常駐Worker処理 Amazon SQS bat101〜106 Queue ©Uzabase, Inc. All Rights Reserved. cron定時バッチ + 手動実行ツール
02 バッチ周辺システムは、Ubuntu12.04のEC2インスタンス全10台 バッチ周辺システム （〜2022） 開発者 編成チーム SSH Slack AWS Cloud Virtual Private Cloud (VPC) 踏み台+ChatOps + 簡易cronタスク Bastion (踏み台サーバ兼 ChatOpsサーバ) SQSをポーリングする常駐Worker cron定時バッチ bat101〜106はスケールアウト可能だが + 手動実行ツール bat001,002は1台でしか動かせない bat000 bat001,bat002 常駐Worker処理 Amazon SQS bat101〜106 Queue ©Uzabase, Inc. All Rights Reserved.
02 バッチ周辺システムが更新されなかった理由 リソースに限りがある中、優先度・緊急度が高くないため後回しにされていた ● Web/APIと比べて、それほど高いデプロイ頻度が求められない ○ Web/APIのバックエンドアプリケーションは200PR/月 以上のデプロイ頻度だが、 バッチ周辺システムは20PR/月くらいなので、開発者体験向上の優先度が急務ではない ○ ● EC2とはいえCodeDeployでデプロイできるなどCI/CDは整備されておりそこまで困ってない Web/APIほど、バージョンアップやセキュリティの危機意識が高まらない ○ 既存のバッチが動いていれば、ランタイムを更新したいモチベーションも特になかった （最新バージョンのKotlinでバッチアプリケーションを書いてもJDK 8で動くので…） ○ インターネットフェイシングではないため定期的なセキュリティパッチ更新運用もなかった ©Uzabase, Inc. All Rights Reserved.
02 じゃぁいつ更新するのか？ → 今年でしょ！ AWSのAPIが、TLS1.1以下の接続をサポート終了するため対応せざるを得なくなった ©Uzabase, Inc. All Rights Reserved.
02 複数のAWSのサービスにアクセスしているが、TLS1.2に未対応 バッチ周辺システム （〜2022） 開発者 編成チーム AWS Cloud Virtual Private Cloud (VPC) bat000 SSH Slack OpenSSLをソースからビルドして バージョンを上げれば延命できるが… Bastion (踏み台サーバ兼 ChatOpsサーバ) Aurora SNS VPC Endpoints S3 bucket bat001,bat002 DynamoDB ElastiCache Amazon SQS 外部API bat101〜106 Queue ©Uzabase, Inc. All Rights Reserved. NAT Gateway
02 常日頃から感じていた運用上の課題もあり、一挙刷新することに 既存のEC2インスタンス10台の運用で感じていた課題 1. 古いインスタンスタイプや仮想化タイプを利用しており、 頻繁にAWSメンテナンスによる再起動対応を強いられる 2. 繰り返し障害になる、定時バッチのスケジュール更新時のcron登録の事故 3. ニュースアプリとしてクリティカルな業務処理である速報プッシュ通知が 定時バッチの実行スケジュールと重なるとOut Of Memoryでkillされる ©Uzabase, Inc. All Rights Reserved.
02 課題①：古いEC2インスタンスはAWSメンテナンスが頻繁にある AWSのデータセンター内で隅っこに追いやられたり再配置されてるのだろうか… このメンテナンス通知を受け取った場合： ● 2:00-4:00 UTCはニュースアプリの ピーク（社会人のお昼休み）時間帯。 ● スケジュールされたメンテナンス前の 夜間に手動で再起動させるしかない ● 古いインスタンスタイプ（c3.xlargeなど）や仮想化タイプ（paravirtual）を 利用しているEC2インスタンスは頻繁にメンテナンス通知がくる 『また！？この前再起動したばっかじゃん、、、』 ©Uzabase, Inc. All Rights Reserved. 定時バッチが動いていないタイミングを確 認して、社内にアナウンスして、夜間に再 起動するというSREチームのトイルになる
02 課題②：定時バッチのスケジュール更新時のcron登録の事故 定時バッチのスケジュールをcrontab -eで修正して本番リリースする怖さ crontabのファイルは一応Gitで管理されており、 PRをマージしてからcrontab -eで書き換える運用 開発者A 『バッチに不具合があって動くとまずいから 取り急ぎ本番crontabからコメントアウト』 開発者B 『定時バッチのスケジュール変更するから、 PRマージしてpullしてGit通り書き換える』 〜時間経過〜 開発者A ©Uzabase, Inc. All Rights Reserved. 『バッチ動いちゃった！まずい！！』 障害
02 課題③：速報プッシュ通知が送れないことがある問題（1/2） ニュースアプリとしてクリティカルな業務処理である速報プッシュ通知 NewsPicksのプッシュ通知の中でも、特に重要な経済 ニュースの速報は時間帯に関わらずChatOpsで配信 👈 動画番組のお知らせプッシュ通知（管理画面で登録） 👈 速報プッシュ通知（Slackコマンドで即時送信） 👈 定時のプッシュ通知（管理画面で登録） ©Uzabase, Inc. All Rights Reserved.
02 課題③：速報プッシュ通知が送れないことがある問題（2/2） バッチ周辺システム （〜2022） 開発者 SSH AWS Cloud Virtual Private Cloud (VPC) チャットボット (Hubot) bat000 Aurora SNS VPC Endpoints S3 bucket expect via SSH 編成チーム Slack Bastion (踏み台サーバ兼 ChatOpsサーバ) bat001,bat002 DynamoDB ElastiCache Amazon SQS 外部API bat101〜106 Queue ©Uzabase, Inc. All Rights Reserved. NAT Gateway
02 課題③：速報プッシュ通知が送れないことがある問題（2/2） バッチ周辺システム （〜2022） 開発者 SSH cron定時バッチが実行中のため、 Out Of Memoryエラーで速報の プッシュ通知処理がkillされる AWS Cloud Virtual Private Cloud (VPC) チャットボット (Hubot) 障害 bat000 Aurora SNS VPC Endpoints S3 bucket expect via SSH 編成チーム Slack Bastion (踏み台サーバ兼 ChatOpsサーバ) bat001,bat002 DynamoDB ElastiCache Amazon SQS 外部API bat101〜106 Queue ©Uzabase, Inc. All Rights Reserved. NAT Gateway
色々つらみがあるということが おわかりいただけたでしょうか じゃぁ、これらを全部コンテナ化したりサーバーレスにすればいいんでしたっけ ©Uzabase, Inc. All Rights Reserved.
03 課題に対する ”頑張りすぎない” 改善策 ©Uzabase, Inc. All Rights Reserved.
03 理想的にはクラウドネイティブ技術のフル活用で課題を解決したい CNCF Cloud Native Definition v1.0 より クラウドネイティブ技術は、パブリッククラウド、プライベートクラウド、ハイブリッドクラウドなどの近代的でダイナミックな環 境において、スケーラブルなアプリケーションを構築および実行するための能力を組織にもたらします。 このアプローチの代表例 に、コンテナ、サービスメッシュ、マイクロサービス、イミュータブルインフラストラクチャ、および宣言型APIがあります。 これらの手法により、回復性、管理力、および可観測性のある疎結合システムが実現します。 これらを堅牢な自動化と組み合わせる ことで、エンジニアはインパクトのある変更を最小限の労力で頻繁かつ予測どおりに行うことができます。 Cloud Native Computing Foundationは、オープンソースでベンダー中立プロジェクトのエコシステムを育成・維持して、このパラ ダイムの採用を促進したいと考えてます。 私たちは最先端のパターンを民主化し、これらのイノベーションを誰もが利用できるよう にします。 https://github.com/cncf/toc/blob/main/DEFINITION.md#cncf-cloud-native-definition-v10 ©Uzabase, Inc. All Rights Reserved.
03 とはいえ、コストコンシャスに課題を解決したい 『10年そのままにするくらい優先度が低かったのに、どれだけコストをかけるのか？』 課題の分類 目的・課題の内容 考えられる対応 外部環境/EOL TLS1.2以上の通信に対応（必達） ● EC2インスタンス再構築(OSバージョンアップ) 運用上の課題 AWSメンテナンスによる再起動対応のトイル削減 ● コンテナ化・サーバーレス化 定時バッチのスケジュール更新時の事故防止 ● IaC化 速報プッシュ通知の処理失敗の根本対策 ● 定時バッチとの競合リソースの分離、疎結合化 固定費割合が多いAWSコストを最適化したい ● pay per useに近いアーキテクチャに変更 外部環境/円安 ©Uzabase, Inc. All Rights Reserved.
03 とはいえ、コストコンシャスに課題を解決したい 『10年そのままにするくらい優先度が低かったのに、どれだけコストをかけるのか？』 課題の分類 目的・課題の内容 考えられる対応 外部環境/EOL TLS1.2以上の通信に対応（必達） ● EC2インスタンス再構築(OSバージョンアップ) 運用上の課題 AWSメンテナンスによる再起動対応のトイル削減 ● コンテナ化・サーバーレス化 定時バッチのスケジュール更新時の事故防止 ● IaC化 速報プッシュ通知の処理失敗の根本対策 ● 定時バッチとの競合リソースの分離、疎結合化 固定費割合が多いAWSコストを最適化したい ● pay per useに近いアーキテクチャに変更 外部環境/円安 これらの課題に対応しつつ、大幅なアプリケーションのコード修正を伴うような コストに見合わない過度なクラウドネイティブ技術の導入はせず、目的を達成する ©Uzabase, Inc. All Rights Reserved.
03 AWSにおける移行戦略『7R』を参考にしました クラウドへの適合度と移行難易度（コスト）のバランスで移行戦略を決定する考え方 https://aws.amazon.com/jp/blogs/news/migrationpath-workshop/ ©Uzabase, Inc. All Rights Reserved.
03 目的や修正コストに応じて移行戦略と採用技術を決定した 全てをコンテナやサーバーレスにすることはせず、一部はEC2で再構築に留めた 大分類 小分類 移行戦略 EC2からの変更 アプリケーション修正 バッチシステム 常駐Worker リプラットフォーム ECS on Fargate なし 定時バッチ リプラットフォーム Step Functions ECS on Fargate なし チャットボット リファクタリング Lambda Hubot → Bolt CoffeeScript→TS プッシュ通知処理 リホスト EC2 なし 踏み台機能 リホスト EC2 - ツール・cron リホスト/リファクタリング EC2, Lambda 一部TSに書き換え ChatOps 踏み台 ©Uzabase, Inc. All Rights Reserved.
00 今日話すこと 1. 10年モノのサービスのクラウド利用状況 2. バッチ周辺システムが10年前のままだった課題 3. 課題に対する ”頑張りすぎない” 改善策 3.1. バッチシステムのリプラットフォーム �� 3.2. プッシュ通知ChatOpsのリファクタリング 3.3. 踏み台サーバ・ツール実行サーバのリホスト 4. まとめ ©Uzabase, Inc. All Rights Reserved.
03 常駐Worker処理をECS on Fargateにリプラットフォーム バッチ周辺システム （〜2022） 開発者 編成チーム SSH Slack AWS Cloud Virtual Private Cloud (VPC) 踏み台+ChatOps + 簡易cronタスク Bastion (踏み台サーバ兼 ChatOpsサーバ) SQSをポーリングする常駐Worker cron定時バッチ bat101〜106はスケールアウト可能だが + 手動実行ツール bat001,002は1台でしか動かせない bat000 bat001,bat002 常駐Worker処理 Amazon SQS bat101〜106 Queue ©Uzabase, Inc. All Rights Reserved.
03 常駐Workerとは何のことを言っているのか 『Web キュー ワーカー』のアーキテクチャの中で常駐するWorker ※イベント駆動での起動と区別している 常に起動して キューをポーリング Azure アーキテクチャセンター - https://learn.microsoft.com/ja-jp/azure/architecture/guide/architecture-styles/web-queue-worker ©Uzabase, Inc. All Rights Reserved.
03 常駐Workerとは何のことを言っているのか 『Web キュー ワーカー』のアーキテクチャの中で常駐するWorker ※イベント駆動での起動と区別している 常に起動して キューをポーリング Azure アーキテクチャセンター ©Uzabase, Inc. All Rights Reserved. クラウドネイティブな考え方では、Webからの キューのスループットや滞留に応じて動的にス https://learn.microsoft.com/ja-jp/azure/architecture/guide/architecture-styles/web-queue-worker ケールできるのが理想と思われる
03 WorkerプロセスごとにECSサービス化し、タスク数を設定 バッチ周辺システム （〜2022） 開発者 SSH AWS Cloud Virtual Private Cloud (VPC) 踏み台+ChatOps + 簡易cronタスク SQSトリガーで起動するLambda関数やECSタスクに cron定時バッチ する方がスケーラビリティやコスト効率は高いが、 アプリケーションの変更コストを抑えて移行するた + 手動実行ツール bat000 めにSQSポーリング×常駐の構成のままとした ECS (常駐Worker) 編成チーム Slack Bastion (踏み台サーバ兼 ChatOpsサーバ) a worker service … polling c worker service b worker service … d worker service … Amazon SQS e worker service Queue ©Uzabase, Inc. All Rights Reserved. … f worker service
03 WorkerプロセスごとにECSサービス化し、タスク数を設定 バッチ周辺システム （〜2022） 開発者 SSH AWS Cloud Virtual Private Cloud (VPC) 踏み台+ChatOps + 簡易cronタスク bat000 cron定時バッチ + 手動実行ツール ECS (常駐Worker) 編成チーム Slack Bastion (踏み台サーバ兼 ChatOpsサーバ) a worker service b worker service … … 並列処理が不可能なWorkerプロセスも、 desiredCount:1,deploymentConfiguration-> c worker service d worker service polling maximumPercent:100にすれば重複起動が発生しない … Amazon SQS e worker service Queue ©Uzabase, Inc. All Rights Reserved. … f worker service
03 動的スケーリングはしないものの、ECS Capacity Providerの機能で 安全にFargate Spotを活用することでコスト効率は高まった バッチ周辺システム （〜2022） 開発者 SSH AWS Cloud Virtual Private Cloud (VPC) 踏み台+ChatOps + 簡易cronタスク cron定時バッチ 各ECSサービス1タスク以外は全てFargate + 手動実行ツール Spotに bat000 することで、EC2時代よりもコストが安くなった ECS (常駐Worker) 編成チーム Slack Bastion (踏み台サーバ兼 ChatOpsサーバ) a worker service … polling c worker service b worker service … d worker service … Amazon SQS e worker service Queue ©Uzabase, Inc. All Rights Reserved. … f worker service
03 定時バッチをStep Functions + ECS on Fargateに変更 バッチ周辺システム （〜2022） 開発者 SSH cron定時バッチが30個くらい登録されてい る。管理画面化されていないエンジニア作業用 のツールをSSHして手動実行する場所でもある AWS Cloud Virtual Private Cloud (VPC) 踏み台+ChatOps + 簡易cronタスク bat000 cron定時バッチ + 手動実行ツール ECS (常駐Worker) 編成チーム Slack Bastion (踏み台サーバ兼 ChatOpsサーバ) a worker service … polling c worker service b worker service … d worker service … Amazon SQS e worker service Queue ©Uzabase, Inc. All Rights Reserved. … f worker service
03 この場を借りてお礼：CNDT2022の発表がとても役に立ちました CNDT2022: バッチシステムをクラウドネイティブにするために考えたこと 古くからシステムの一部として利用されてきたバッチ システムですが、運用しやすいバッチシステムの設計 ・構築にはwebアプリケーションとは異なる着眼点が 必要となります。 本セッションでは、クラウドネイティブ時代に求めら れるバッチシステムの性質について整理し、弊社のプ ロダクトでバッチシステムをVMベースから StepFunction+ECS Fargateベースへ移行させた事 例、及びその中で発生したトラブルと対処法について お話します。 AWS起因のプロビジョニングエラーに対する自動リトライ、 https://cloudnativedays.jp/cndt2022/talks/1518 重複起動の抑止など、先に検討ポイントを上げていただいた ことでスムーズに実装できました！ありがとうございます！！ ©Uzabase, Inc. All Rights Reserved.
03 定時バッチをStep Functions + ECS on Fargateに変更 バッチ周辺システム （2023〜） 開発者 SSH cron定時バッチ30個をIaCの設定を元に EventBridge Ruleのcronで起動する Step Functions workflowに変更 AWS Cloud Virtual Private Cloud (VPC) Step Functions workflow 踏み台+ChatOps + 簡易cronタスク EventBridge Rule(cron) 定時バッチ 重複起動確認→Run Task→Timeout ECS (常駐Worker) 編成チーム Slack Bastion (踏み台サーバ兼 ChatOpsサーバ) a worker service … polling c worker service b worker service … d worker service … Amazon SQS e worker service Queue ©Uzabase, Inc. All Rights Reserved. … f worker service
03 cron設定も、PRでレビューしてIaCで適用できるようになった IaCの設定ファイル （〜2022） 開発者 SSH cron定時バッチ30個をIaCの設定を元に EventBridge Ruleのcronで起動する Step Functions workflowを作成 Virtual Private Cloud (VPC) Step Functions workflow 踏み台+ChatOps + 簡易cronタスク EventBridge Rule(cron) 重複起動確認→Run Task→Timeout ECS (常駐Worker) 編成チーム Slack Bastion (踏み台サーバ兼 ChatOpsサーバ) cdk deploy a worker service … polling c worker service … d worker service … e worker service … ©Uzabase, Inc. All Rights Reserved. b worker service f worker service
00 今日話すこと 1. 10年モノのサービスのクラウド利用状況 2. バッチ周辺システムが10年前のままだった課題 3. 課題に対する ”頑張りすぎない” 改善策 3.1. バッチシステムのリプラットフォーム �� 3.2. プッシュ通知ChatOpsのリファクタリング 3.3. 踏み台サーバ・ツール実行サーバのリホスト 4. まとめ ©Uzabase, Inc. All Rights Reserved.
03 なかなか香ばしい構成で動いていたChatOps、直したい バッチ周辺システム （〜2022） 開発者 SSH AWS Cloud Virtual Private Cloud (VPC) チャットボット (Hubot) bat000 Aurora SNS VPC Endpoints S3 bucket expect via SSH 編成チーム Slack Bastion (踏み台サーバ兼 ChatOpsサーバ) bat001,bat002 DynamoDB ElastiCache Amazon SQS 外部API bat101〜106 Queue ©Uzabase, Inc. All Rights Reserved. NAT Gateway
03 なかなか香ばしい構成で動いていたChatOps、直したい バッチ周辺システム （〜2022） 開発者 SSH AWS Cloud Hubot自体がほとんどメンテナン スされておらず、Slackの非推奨 APIを利用しており、未来がない Virtual Private Cloud (VPC) チャットボット (Hubot) bat000 Aurora SNS VPC Endpoints S3 bucket expect via SSH 編成チーム Slack Bastion (踏み台サーバ兼 ChatOpsサーバ) bat001,bat002 DynamoDB ElastiCache Amazon SQS 外部API bat101〜106 Queue ©Uzabase, Inc. All Rights Reserved. NAT Gateway
03 なかなか香ばしい構成で動いていたChatOps、直したい バッチ周辺システム （〜2022） 開発者 SSH AWS Cloud チャットボットからバッチサーバーに SSHしてプッシュ通知ツールを実行 Virtual Private Cloud (VPC) チャットボット (Hubot) bat000 Aurora SNS VPC Endpoints S3 bucket expect via SSH 編成チーム Slack Bastion (踏み台サーバ兼 ChatOpsサーバ) bat001,bat002 DynamoDB ElastiCache Amazon SQS 外部API bat101〜106 Queue ©Uzabase, Inc. All Rights Reserved. NAT Gateway
03 チャットボットのライブラリと実装コードは全て刷新しサーバーレス化 コード量が少なかったので、Slack公式の フレームワークを利用してHubotの CoffeeScriptをTypeScriptに書き直した SNS 編成チーム Bolt Slack Slack webhook チャットボット Lambda関数 ©Uzabase, Inc. All Rights Reserved. SSM Run Command tools (ツール実行サーバ) Aurora
03 一方、プッシュ通知実行処理は、速報の要件上EC2インスタンスを維持 SNS 編成チーム Bolt Slack Slack webhook チャットボット Lambda関数 SSM Run Command tools (ツール実行サーバ) Aurora ECS Run TaskでFargateを利用することも検討したが、コンテ ナイメージのダウンロード時間の分遅くなってしまったため、 EC2 インスタンスを再構築し継続採用 ©Uzabase, Inc. All Rights Reserved.
00 今日話すこと 1. 10年モノのサービスのクラウド利用状況 2. バッチ周辺システムが10年前のままだった課題 3. 課題に対する ”頑張りすぎない” 改善策 3.1. バッチシステムのリプラットフォーム 3.2. プッシュ通知ChatOpsのリファクタリング �� 3.3. 踏み台サーバ・ツール実行サーバのリホスト 4. まとめ ©Uzabase, Inc. All Rights Reserved.
03 残った2台のインスタンスは最新のOSに変更して再構築 バッチ周辺システム （2023〜） 開発者 AWS Cloud Virtual Private Cloud (VPC) Step Functions workflow SSM Session Manager EventBridge Rule(cron) 踏み台 SSH Bastion 編成チーム 定時バッチ 重複起動確認→Run Task→Timeout Ubuntu12→Amazon Linux 2023へ ECS (常駐Worker) a worker service 簡易cronタスク+ツール … Slack EventBridge SSM Run Rule(cron) Command ChatOps tools c worker service ©Uzabase, Inc. All Rights Reserved. … d worker service … e worker service … チャットボット SSM Run Lambda関数 Command b worker service f worker service
03 踏み台のcronはLambdaに移行や廃止するなどして完全に撤廃 バッチ周辺システム （2023〜） 開発者 AWS Cloud Virtual Private Cloud (VPC) SSM Session Manager EventBridge Rule(cron) 踏み台 SSH 定時バッチ a worker service 簡易cronタスク+ツール … Slack EventBridge SSM Run Rule(cron) Command ChatOps 重複起動確認→Run Task→Timeout ECS (常駐Worker) Bastion 編成チーム Step Functions workflow 踏み台以外の役割を撤廃 tools c worker service … d worker service … e worker service Lambdaへの移行ができず、サーバーで … 動かす定時処理も、crontabではなく チャットボット SSM Run IaCで管理できるようになった Lambda関数 Command ©Uzabase, Inc. All Rights Reserved. b worker service f worker service
04 まとめ ©Uzabase, Inc. All Rights Reserved.
04 当初の課題とその対応 全てがクラウドに最適化されたわけではないが、当初の課題はほとんど解消 課題の分類 目的・課題の内容 行った対応と成果 外部環境/EOL (MUST) TLS1.2以上の通信に対応（必達） ✅ 10台のUbuntu12が完全に廃止され、コンテナ・ サーバーレス・Amazon Linux2023になり、全 てのシステムでTLS1.2以上の通信に対応した 運用上の課題 (SHOULD) AWSメンテナンスによる再起動対応のトイル削減 ✅ 2台を除いてコンテナ化・サーバーレス化した ため、再起動対応の頻度は激減 定時バッチのスケジュール更新時の事故防止 ✅ cron設定がIaC化され、コード管理とともに 定時バッチを更新する運用が常識になった 速報プッシュ通知の処理失敗の根本対策 ✅ バッチは全てFargateになったため、プッシュ通 知処理とバッチはリソース競合しなくなった 固定費割合が多いAWSコストを最適化したい ✅ コンテナ化により一定のコスト最適化ができた 🔺 動的なスケーリングは実施できていない 外部環境/円安 (BETTER) ©Uzabase, Inc. All Rights Reserved.
04 ● 本日お伝えしたかったこと クラウドネイティブ技術の導入を判断する上でコストコンシャスな移行戦略の重要性 ○ ● 移行難易度(コスト)と期待する成果を観点に入れることで、対応方針を決めやすくなる 課題解決の目的意識を持つことで、クラウドネイティブを”頑張らなくていい”判断ができる ○ 例: 安定化が課題だった速報プッシュ通知はコンテナ化するとプロセス起動までの 時間が伸びるので、常時起動のEC2インスタンスにコマンドを送る方が適していた ○ ● 例: プッシュ通知と定時バッチのリソース競合は、片方をFargateにすれば解決できる コンテナ化やサーバーレスのようなクラウドネイティブ技術を導入できなくても、 特定のクラウドベンダーのサービスでVMのまま問題を解決できる可能性がある ○ AWSならEventBridge Rule+SSM Run CommandでEC2インスタンスのcrontabを卒業できた ©Uzabase, Inc. All Rights Reserved.
”頑張りすぎないクラウドネイティブ”で 事業の課題解決を楽しんでいきましょう！ ご清聴ありがとうございました！ ©Uzabase, Inc. All Rights Reserved.