Slide 1

Slide 1 text

2020/9/18 オンライン勉強会 https://www.lancers.jp/ Yuki Kanazawa 本番環境の ECS/Fargate採用

Slide 2

Slide 2 text

2020/9/18 オンライン勉強会 自己紹介 2 氏名:金澤 裕毅 出身:宮城県仙台市 Lancers, Inc. / Site Reliability Engineer (2013/11 -) 趣味: 将棋(ウォーズ初段、将棋倶楽部24で1000点くらい) Github:yKanazawa Twitter: @yakitori009 Language: C++, Java, PHP, Go

Slide 3

Slide 3 text

2020/9/18 オンライン勉強会 About Lancers https://www.lancers.jp/ Genre: Crowdsourcing Start: 2008/4 PHP 5.2 → 5.3 → 5.6 → 7.3 CakePHP 1.2 → 1.3 → 2.8 → 2.10 2017年時点 現在

Slide 4

Slide 4 text

2020/9/18 オンライン勉強会 4 ランサーズのサーバー構成 EC2 instance CloudSearch CloudFront Route 53 CloudFront ALB ALB API Gateway Lambda Auto Scaling App S3 Aurora Reader Aurora Reader Aurora Writer Api ElastiCache Redis AI系API サムネイル表示 仕事検索 ランサー検索 ランサーズ Batch PHP7 CakePHP2.10 Python3 MySQL5.7

Slide 5

Slide 5 text

2020/9/18 オンライン勉強会 開発環境Docker化の経緯

Slide 6

Slide 6 text

2020/9/18 オンライン勉強会 6 VMをDockerに置き換え 192.168.33.15 HDD 50GB メモリ 1GB 認証システム 192.168.33.11 HDD 50GB メモリ 2GB App(ランサーズ本体) Apache 2.2 (80) PHP 5.3 MySQL 5.6 (3306) Memcached(11211) 192.168.33.13 HDD 50GB メモリ 1GB WordPress (コーポレート、ブログ等) Apache 2.4(80) PHP 5.5 MySQL 5.6(3306) 192.168.33.12 HDD 50GB メモリ 1GB メッセージ(チャット) Nginx(3443) node.js(3001) Redis(6379) HDD 20GB メモリ 2GB 172.17.6.11 App(ランサーズ本体) Apache 2.2 (80) PHP 5.3 172.17.4.51 コーポレート、ブログ等) Apache 2.4(80) PHP 5.5 172.17.4.152 メッセージ(チャット) Nginx(3443) node.js (3001) 172.17.106.55 認証システム 新サービス開発の度に VMを作成 1つのVMに 各種コンテナを配置

Slide 7

Slide 7 text

2020/9/18 オンライン勉強会 7 Docker移行の方針 ●本番環境と極力同じ構成を再現 ○AWSのマネージド系のサービス ■Dockerfileで作成 ○AWSのEC2で構築しているサーバー ■Dockerfile + Ansibleで作成 ■Ansibleを実行するコンテナを用意 ●本番と同じPlaybookで構築 App ELB ErastiCache Memcached ErastiCache Redis Aurora EC2 instance Wordpress EC2 instance WebSocket App Redis MySQL ELB WordPress Memcached WebSocket EC2 instance ELB RDS ELB SSL Terminate リバースプロキシ データ入り

Slide 8

Slide 8 text

2020/9/18 オンライン勉強会 8 Docker移行の方針 EC2 MySQLデータ 開発用データ App Ansible WordPress MySQL WebSocket WordPress App WebSocket MySQL Playbook docker push docker pull docker build Amazon ECR ●構築に時間をかけない ○コンテナをpullするだけで完了 コンテナは インフラチームが構築 アプリチームは コンテナをpullするだけ

Slide 9

Slide 9 text

2020/9/18 オンライン勉強会 リリース環境について

Slide 10

Slide 10 text

2020/9/18 オンライン勉強会 10 リリースの自動化と委譲 ●Webからリリース可能なシステムを構築 ○アプリエンジニアやデザイナーでもリリース可能

Slide 11

Slide 11 text

2020/9/18 オンライン勉強会 11 リリースフロー EC2 App Deploy EC2 instance EC2 Canaria App EC2 instance Developer ●Githubにpush

Slide 12

Slide 12 text

2020/9/18 オンライン勉強会 12 リリースフロー EC2 App Deploy EC2 instance EC2 Canaria App EC2 instance Developer ●Webデプロイシステムからリリース

Slide 13

Slide 13 text

2020/9/18 オンライン勉強会 13 リリースフロー EC2 App Deploy EC2 instance EC2 Canaria App EC2 instance Developer ●DeployサーバーがGithubからpull

Slide 14

Slide 14 text

2020/9/18 オンライン勉強会 14 リリースフロー EC2 App Deploy EC2 instance EC2 Canaria App EC2 instance composer install Developer ●composer installの実行 ○開発用Appコンテナを起動

Slide 15

Slide 15 text

2020/9/18 オンライン勉強会 15 リリースフロー EC2 App Deploy EC2 instance EC2 Canaria App EC2 instance rsync Developer ●カナリア環境にrsync ○最終確認

Slide 16

Slide 16 text

2020/9/18 オンライン勉強会 16 リリースフロー EC2 App Deploy EC2 instance EC2 Canaria App EC2 instance rsync Developer ●本番環境にrsync

Slide 17

Slide 17 text

2020/9/18 オンライン勉強会 17 リリースシステム EC2 App Deploy EC2 instance EC2 Canaria App EC2 instance S3 Cloud Front rsync 静的 ファイル キャッシュ クリア composer install node install go build Wordpress EC2 instance EC2 Api Developer ●ランサーズ以外のサービスにも拡張 ○unicornの再起動 ○S3への配置 ○CloudFrontのキャッシュクリア

Slide 18

Slide 18 text

2020/9/18 オンライン勉強会 本番環境のDocker化検討

Slide 19

Slide 19 text

2020/9/18 オンライン勉強会 本番環境をDocker化するメリット・デメリット ●メリット ○リリースの仕組みを作りやすい ■CIでコンテナごとリリース ■ChatOpsでのリリースも作りやすい ○ミドルウェアの変更がリリースで可能 ■PHPのバージョンアップ等 ○素早く柔軟なオートスケーリング ■起動が早い ●デメリット ○リリースに時間がかかる ■リリースの度にコンテナを再構築 ■3分以上はかかる ○サーバー費用 ■Fargateでも割高

Slide 20

Slide 20 text

2020/9/18 オンライン勉強会 現サービスをDockerしていない理由 ●リリースの仕組みが既にできている ●リリースにかかる時間 ○現リリースシステムは30秒でリリースできる ●サーバー費用 ○現状、EC2で運用した方がFargateより安い ●新サービスなら採用しても良いかも

Slide 21

Slide 21 text

2020/9/18 オンライン勉強会 新サービスにDockerを採用した理由 ●リリースの仕組みを作らなくて良いこと ○CircleCIでリリース ○検証環境にコマンドでリリース ■CircleCIのAPIを叩く ●オートスケーリングの仕組みを作らなくて良いこと ○EC2の場合 ■AMIから起動時に最新ソースを取得 ■ミドルウェアの更新時にAMIの更新が必要 ○Dockerの場合 ■リリースの都度コンテナを作成 ■リリースしたコンテナはImmutable ●ミドルウェアの更新を開発者に任せられること ○EC2の場合 ■手動で適用してAMIの更新が必要 ○Dockerの場合 ■Dockerfileを修正してもらえばOK

Slide 22

Slide 22 text

2020/9/18 オンライン勉強会 EKSを採用しなかった理由

Slide 23

Slide 23 text

2020/9/18 オンライン勉強会 Kubernetesの役割 ●サービスディスカバリーと負荷分散 ●ストレージ オーケストレーション ●自動化されたロールアウトとロールバック ●自動ピンバック ●自己修復 ●機密情報と構成管理

Slide 24

Slide 24 text

2020/9/18 オンライン勉強会 Kubernetesを採用しなかった理由 ●ECSの方がリリースが早かった ○知見を以前より貯めていた ●AWSのインフラ運用のノウハウを活用したい ○Kubernetesの新しい概念を学習するコスト ●頻繁で互換性のないバージョンアップ ○新バージョンへの追従が難しい ■新しい概念を都度学習して適用する必要性 ●小規模なモノリスのサービスで採用する意義 ○簡単な新規サービスで採用する運用コスト

Slide 25

Slide 25 text

2020/9/18 オンライン勉強会 Kubernatesの採用条件 ●Kubernetes採用のメリットがでそうな条件 ○マルチクラウドで冗長化するパターン ■運用をKubernetesに統一できる ○マイクロサービスで構築するパターン ■サービス群を統合的に操作したい場合 ●ECS/Fargateのこれからにも期待 ●Kubernetesの採用条件 ○落ち着いたバージョンアップ ■追従が難しくなくなる程度に。。 ○Kubernetesがデファクトスタンダードになった場合 ■共通ツールとしての地位を確立した場合