PowerPoint Presentation

Transcription

1 FiNC を支えるインフラ技術 ECS と DevOps

2 自己紹介 名前 : 中村郷史 ( なかむらさとし ) 所属 : プロダクト本部技術開発部 SREグループ 担当 : Technical Lead in SRE 社歴 : 2017 年 1 月ジョイン 約 1 年半 よく使っているAWSのサービス ECS CloudFormation

3 人の行動を変え 健康を実現するヘルスケアカンパニー < O u r V i s i o n > 一生に一度のかけがえのない人生の成功をサポートする

4 健康寿命 という言葉はご存知ですか?

5 人の支えがなければ 生きられなくなってしまう 年齢のことを言います

6

7 寝たきりの原因 その他 26% 脳卒中 24.1 % 厚生労働省 国民基礎調査より 関節疾患 7% 骨折 認知症 21% 9% 衰弱 13%

8 生活習慣の改善 に必要な三要素 栄養 運動 休養 1 2 何をすべきか分からない 継続できない

9 Mission すべての人にパーソナルコーチを

10 FiNC のサービス 広告 有料課金 EC FiNC インタラクティブコミュニケーション

11 ライフログがたまるほど あなたにフィットするパーソナルトレーナー AI アプリ

12 FiNC アプリ ライフログの記録 動画コンテンツ SNS 歩数 睡眠時間が自動で記録体重 食事 生理日なども モデルやアスリート 栄養士 / トレーナー等によるヘルシーレシピ フィットネス等の動画 家族や友達 著名人 専門家と楽しくコミュニケーション

13 FiNC のシステム マイクロサービス アーキテクチャ

14 マイクロサービスとは 決済機能 ライフログ機能ランキング機能チャット機能 API API 主機能 API アカウント管理機能企業管理機能 AI 機能 ライフログ機能ランキング機能チャット機能グループ機能 決済機能 AI 機能アカウント管理機能姿勢解析機能企業管理機能 主機能 グループ機能 API API 姿勢解析機能 マイクロサービス アーキテクチャ モノリシック アーキテクチャ

15 なぜマイクロサービスか? ヘルスケアの中で様々なサービスを提供するというビジネス構想があったから FiNC インタラクティブコミュニケーション

16 アジェンダ なぜ ECS にしたのか ECS Tips ECS 事件簿

17 アジェンダ なぜ ECS にしたのか ECS Tips ECS 事件簿

18 ECS 以前の構成の振り返り EC2 Ansible Capistrano

19 EC2 時代の問題点 スケール性能サーバの起動 構築からサービスに組み込まれる時間 余剰リソース余剰 CPU メモリの有効活用 多様な構成管理 OS 言語 フレームワーク バージョン等 異なる設定管理非同期処理 DB 設定 環境設定

20 なぜ ECS にしたのか スケール性能コンテナ ( サーバ ) 増強の速さ リソース最適化 1 台のサーバリソースを使いきれる ( 最大 70コンテナ稼動 ) 多様な構成管理 異なる設定管理 SREが中央管理するのではなく 開発側に委譲

21 なぜ ECS にしたのか スケール性能コンテナ ( サーバ ) 増強の速さ リソース最適化 1 台のサーバリソースを使いきれる ( 最大 70コンテナ稼動 ) 多様な構成管理 異なる設定管理 SREが中央管理するのではなく 開発側に委譲

22 構成管理ファイル 多様な構成 OS 言語 フレームワーク バージョン等初期 :Ansible(Ops) 移行期 :Dockerfile(Ops) 現在 :Dockerfile(Dev) 異なる設定 非同期処理 DB 設定 環境設定初期 :Capistrano(Ops) 移行期 :Envfile(Ops) 現在 :Envfile(Dev) Envfile 環境変数によってデプロイフロー使い分けているファイル

23 ECS 移行期間 方法 移行期間約半年 移行方法 Route53 RoutingPolicy: Weighted EC2 99% ECS 1% => 5% => 30% => 100% 1 日放置 エラー リソース確認

24 トラフィック推移

25 ECS に移行した結果 スケール性能急激なトラフィックに耐えられるようになった 余剰リソース集約率向上 => 1コンテナインスタンスに平均約 20タスク 多様な構成開発者がSREに依頼することなく変更が可能 異なる設定開発者がSREに依頼することなく変更が可能

26 アジェンダ なぜ ECS にしたのか ECS Tips ECS 事件簿

27 発表内容の全体像 CI/Monitoring Jenkins ECS Cluster gateway Build Test Deploy Utility Amazon ECR S3 Lambda function Batch Jenkins worker Task Definition RDS Amazon CloudWatch doker pull docker exec Application ALB RedShift

28 Tips1 DB マイグレーション実行方法

29 デプロイフロー Build Test Deploy docker run package install db create test code (image upload) migration ECS TaskDefinition update ECS Service update

30 どうしたか? アプリケーションクラスターと 同じクラスターを作る

31 デプロイフロー デプロイフロー 1. utility クラスターのサービス更新 Build Test Deploy 1 ECS 2 gateway 2. 画像アップロード 3. migration 4. Applicationクラスターのサービ Utility 3 S3 ス更新 4 RDS EC2 rails console の実行 Application ALB

32 Tips2 テスト高速化

33 ある日 テストめちゃくちゃ遅いんですけど

34 デプロイフロー ( 再掲 ) Build Test Deploy docker run package install db create test code (image upload) migration ECS TaskDefinition update ECS Service update

35 テストフロー 開発者 1 GitHub テストフロー 1. 開発者が GitHub に push/merge ECS S3 2. イメージをpull 3. コンテナを起動 Build Test Deploy 4. 必要パッケージをインストール Amazon ECR 5. db create 6. テストコード実行 Task Definition ECS Cluster Service

36 どうしたか? 環境に変更がない場合はビルド処理をスキップ

37 環境構成チェック方法 対象ファイル ディレクトリをSHA256に変換 インストール Dockerfile Gemfile マイグレーション db/migrate

38 テストフロー ( 改善版 ) 開発者 1 GitHub 2 6 テストフロー 1. 開発者が GitHub に push/merge ECS S3 2. config check 3. ECRからインストール済みイ Build Test Deploy メージを pull Amazon ECR 4. コンテナを起動 5. 必要パッケージをインストール Task Definition 6. config check 7. db create 8. テストコード実行 ECS Cluster Service

39 実測値 15 分 -> 5 分

40 Tips3 オートスケール方法

41 スケールイン / アウト (ECS) ECS publish metrics スケールイン / アウト 1. unicorn worker num task1 1 2 get metrics 2. lambda function をCloudWatchに送る 4. トリガー発動 task2 4 3 Lambda function publish metrics Auto Scaling ScaleIn/Out Amazon CloudWatch

42 スケールアウト (EC2) EC2 publish metrics 1 Amazon CloudWatch スケールアウト 1. CPU Utilization 2. Scale Out task1 task2 2 Scaleout Auto Scaling

43 スケールアウト (EC2) EC2 Amazon CloudWatch スケールアウト publish metrics 1. CPU Utilization 1 2. monitoring 3. draining/terminate task1 3 2 monitoring task2 draining/terminate

44 Tips4 バッチ処理実行方法

45 EC2 時代 cron で実行

46 どうしたか? バッチ用の Jenkins

47 バッチ用 Jenkins Batch Jenkins In-house-tool doker pull 4 docker exec 1 2 ECS ECS Cluster Service ジョブ例 ServieName=AAA Container=rails batch-tool bundle exec rake XXX 3 Task Definition Amazon ECR バッチ実行方法 1. タスク定義を検索 2. リポジトリとタグを検索 3. docker pull 4. コマンド実行

48 Tips5 Dockerfile の管理

49 構成管理ファイル 多様な構成 OS 言語 フレームワーク バージョン等 Dockerfile 異なる設定非同期処理 DB 設定 環境設定 Envfile

50 Dev が管理 管理しているもの Dockerfile Envfile( 環境変数 ) 徐々に移行 管理していないものオートスケールの設定

51 アジェンダ なぜ ECS にしたのか ECS Tips ECS 事件簿

52 問題 1 fluentd サーバ SPOF 問題

53 fluentd を使っている理由 awslogs( 当時 ) 30GB/ 日 x 15 サービス =450GB 450GB x $0.76=$342/ 日 x 30day = $10,260/ 月 fluentd を使った

54 ある日 なぜかコンテナが起動しない

55 原因 fluentd サーバに障害 コンテナが上がらない

56 fluentd の設定 ECS S3 application log access log activity log RedShift

57 どうしたか? コンテナホストに fluentd の中継サーバーを立てる

58 fluentd の中継 ECS application log access log S3 activity log RedShift

59 問題 2 ( ラスト ) push 通知重複問題

60 ある日 1 人に同じプッシュ通知が重複して届く

61 原因 非同期処理ワーカーが処理中にコンテナが停止してしま い 最初から処理を再開 ECS タスクの停止動作 $ kill -SIGTERM (kill -15) $ kill -SIGKILL (kill -9)

62 どうしたか? $ kill -USR1 停止シグナルを送ってから 停止するまで待つ コンテナ監視を社内で構築

63 ワーカー監視方法 monitoring Jenkins In-house-tool 1 3 ECS 2 ECS Cluster Service System Manager 1. 稼働中のタスクの最大メモリとワーカー数を確認 2. SystemManager にメモリとワーカー数を問い合わせ 3. 最大メモリ値を超えたタスクに対してユーザシグナルを送りタスクを終了

64 ライフログがたまるほど あなたにフィットするパーソナルトレーナー AI アプリ

65 採用 エンジニア採用してます SiteReliabilityエンジニア サーバサイドエンジニア (Rails) iosエンジニア Androidエンジニア

66 エンジニアブログ Redshift ディスク使用量削減大作戦 細部カイゼン合宿が思ったより有意義だった件 マイクロサービス指向 Rails API 開発ガイド この後 AWS Summit Tokyo の話しもアップします

67 Thank you