$30 off During Our Annual Pro Sale. View Details »

ランサーズで積み重ねたSRE的取り組みとこれから

Kanazawa Yuki
February 21, 2018

 ランサーズで積み重ねたSRE的取り組みとこれから

2018/2/21 のtechplayで発表した資料です。
https://techplay.jp/event/654623?utm_source=event_654623&utm_medium=social&utm_campaign=feed&utm_content=tw731068152189059073

話したいことはたくさんありましたら時間の関係で結構削りました。

Kanazawa Yuki

February 21, 2018
Tweet

More Decks by Kanazawa Yuki

Other Decks in Technology

Transcript

  1. 2018/2/20 TechPlay 自己紹介 3 氏名:金澤 裕毅 出身:宮城県仙台市 入社時期:2013年11月 略歴: 大学時代はネットワークを専攻

    Windowsパッケージ開発(C++) ASP開発(Java)&インフラ(オンプレ) SNS開発(PHP)&インフラ(オンプレ) ランサーズのインフラ(AWS)
  2. 2018/2/20 TechPlay 9 ランサーズのサーバー構成図(2012/5 – )AWS移行初期 App S3 ELB App

    Route53 EC2 instance WebSocket Memcached DB Slave DB Master EC2 EC2 instance EC2 instance EC2 instance EC2 instance EC2 instance NFS EC2 instance
  3. 2018/2/20 TechPlay 10 ランサーズのサーバー構成図(現在) App S3 ELB App CloudFront Cloud

    Search Route53 EC2 instance WebSocket ErastiCache Memcached ErastiCache Redis Aurora Reader Aurora Writer Api ELB Api EC2 EC2 instance ErastiCache Redis EC2
  4. 2018/2/20 TechPlay インフラメンバーとサービス数 12 アプリエンジニアが兼任 インフラ専任1名 + アプリエンジニア 2008 /

    12 2013 / 11 2016 / 3 2017 / 10 インフラ専任2名 + アプリエンジニア インフラ専任2名 + 新卒1名 + インターン1名 + アプリエンジニア 5 10 15 25 20
  5. 2018/2/20 TechPlay インフラチームの業務 14 サーバー運用 安定化 レスポンス改善 負荷改善 冗長化 セキュリティ対策

    最新バージョン追従 リソース管理 新サービスローンチ支援 キャパシティプランニング ドメイン、SSL証明書、リポジトリ管理 サーバー費用削減 旧サービス、旧機能の削除 効率化 サーバーのコード化 定型作業の自動化 開発支援 開発環境構築 リリースシステム構築 旧ソースの削除 社内インフラ、情シス系 社内サーバー 社内LAN PC周り 定型作業の委譲 他
  6. 2018/2/20 TechPlay インフラチームの業務 15 サーバー運用 安定化 レスポンス改善 負荷改善 冗長化 セキュリティ対策

    最新バージョン追従 リソース管理 新サービスローンチ支援 キャパシティプランニング ドメイン、SSL証明書、リポジトリ管理 サーバー費用削減 旧サービス、旧機能の削除 効率化 サーバーのコード化 定型作業の自動化 開発支援 開発環境構築 リリースシステム構築 旧ソースの削除 社内インフラ、情シス系 社内サーバー 社内LAN PC周り 定型作業の委譲 他 •SREとして認知されている業務
  7. 2018/2/20 TechPlay インフラチームの業務 16 サーバー運用 安定化 レスポンス改善 負荷改善 冗長化 セキュリティ対策

    最新バージョン追従 リソース管理 新サービスローンチ支援 キャパシティプランニング ドメイン、SSL証明書、リポジトリ管理 サーバー費用削減 旧サービス、旧機能の削除 効率化 サーバーのコード化 定型作業の自動化 開発支援 開発環境構築 リリースシステム構築 旧ソースの削除 社内インフラ、情シス系 社内サーバー 社内LAN PC周り 定型作業の委譲 他 •ランサーズのインフラチームが重視している業務 インフラチームを介さずに 完結できる仕組みの構築
  8. 2018/2/20 TechPlay インフラチームの業務 17 サーバー運用 安定化 レスポンス改善 負荷改善 冗長化 セキュリティ対策

    最新バージョン追従 リソース管理 新サービスローンチ支援 キャパシティプランニング ドメイン、SSL証明書、リポジトリ管理 サーバー費用削減 旧サービス、旧機能の削除 効率化 サーバーのコード化 定型作業の自動化 開発支援 開発環境構築 リリースシステム構築 旧ソースの削除 社内インフラ、情シス系 社内サーバー 社内LAN PC周り 定型作業の委譲 他 •スタートアップで必要とされる業務 組織が拡大すれば 管理部に委譲できる クラウド化も選択肢
  9. 2018/2/20 TechPlay MyIsam→InnoDBに移行 19 •MySQLのFULLTEXT インデックスが度々壊れ、サービスが全停止 ◦MySQL5.1ではMyISAMでしか利用できなかった ▪トランザクション未対応 •RDSに移行し、MySQL5.6にバージョンアップ ◦InnoDBでFULLTEXT

    インデックスが利用できるように ▪トランザクション対応 DB Master DB Slave001 DB Slave002 DB Slave003 DB Slave004 DB MultiAZ DB Master DB Slave001 EC2 EC2 DB Slave002 EC2 DB Slave003 EC2 DB Slave004 EC2 MySQL5.1 MySQL5.6
  10. 2018/2/20 TechPlay 21 VPCの細分化、MultiAZ化 AWS Cloud Virtual Private Cloud ap-northeast-1c

    Master Slave001 Slave003 Batch1 KPI EC2 instance EC2 App ap-northeast-1a Asterisk EC2 instance PrivateApp EC2 instance EC2 App Route53 10.0.151.0/24 10.0.52.0/24 10.0.152.0/24 EC2 10.0.51.0/24 Slave002 Mail Websocket EC2 instance EC2 instance LJP EC2 instance Gateway LJPPrivate LJP 10.0.104.0/24 10.0.106.0/24 10.0.150.0/24 10.0.6.0/24 10.0.4.0/24 10.0.1.0/24 10.0.101.0/24 NAT 10.0.50.0/24 S3 Bucket EC2 instance NAT EC2 instance MultiAZ Master Slave001 Batch KPI EC2 instance EC2 Ap ap-northeast-1b Asterisk EC2 instance PrivateApp EC2 instance EC2 10.0.1.0/24 Mail Websocket EC2 instance EC2 instance LJP LJPPrivate NAT 10.0.0.0/24 EC2 instance Slave002 Slave003 •新インスタンスが使えるAZに引っ越し ◦2つのAZに分散し、サブネットを細分化 新インスタンスが 使えないAZ
  11. 2018/2/20 TechPlay 2つのAZに分散する意味 22 RDS Master RDS Read Replica App

    ap-northeast-1a EC2 instance ELB App EC2 instance App EC2 instance RDS Multi AZ RDS Read Replica App ap-northeast-1c EC2 instance ELB App EC2 instance App EC2 instance AZ間の通信遅延は 数ミリ〜数十ミリ secレベル Route53
  12. 2018/2/20 TechPlay 2つのAZに分散する意味 23 RDS Multi AZ RDS Master RDS

    Read Replica App ap-northeast-1a EC2 instance ELB App EC2 instance App EC2 instance RDS Read Replica App ap-northeast-1c EC2 instance ELB App EC2 instance App EC2 instance Route53 •AZレベルの障害を想定
  13. 2018/2/20 TechPlay 26 負荷、レスポンス対策 •サーバー負荷、レスポンスは継続的に改善が必要 ◦放っておくと悪化する一方 •負荷、レスポンスの悪化要因 ◦アクセス数の増加 ◦データ数の増加 ◦サービスの機能追加

    •レスポンスの種類 ◦サーバーレスポンス ▪極端に遅いページが1つでもあるとユーザーは不快に感じる •DBが原因であることがほとんど ◦ブラウザレスポンス ▪CDN等で対策 ▪フロントエンジニアやデザイナーと協力して改善
  14. 2018/2/20 TechPlay 27 アプリケーションサーバーのチューニング •AWSのサーバーサイズに合わせた設定が必要 ◦メモリ、CPU比率が固定されている •CPU最適化インスタンスの場合 ▪c4.large •2コア •3.75GB

    ▪c4.xlarge •4コア •7.5GB •CPUを利用してメモリを節約 移行前 移行後 <IfModule prefork.c> StartServers 10 MinSpareServers 10 MaxSpareServers 20 ServerLimit 190 MaxClients 190 MaxRequestsPerChild 50 </IfModule> デフォルトは3000 プロセスをこまめに削除 してメモリを確保
  15. 2018/2/20 TechPlay 28 アプリケーションサーバーの負荷、レスポンス対策 •ELBのSSL Terminationの利用 ◦EC2内はhttpで処理 ▪SSL機能を使わなくなり、メモリ使用量が半減 •CDN(CloudFront)の利用 ◦静的ファイルをCloudFrontにキャッシュ

    ▪ブラウザレスポンスの改善 ▪リクエスト削減によるサーバー負荷の改善 EC2 ELB https://www.lancers.jp/ http://www.lancers.jp/ SSL Terminate EC2 ELB EC2 ELB https://static.lancers.jp/ CloudFront https://static.lancers.jp/
  16. 2018/2/20 TechPlay 30 サーバーのスケールアップ •C3系→C4系インスタンスへの移行 ◦PV → HVM AMIへ移行 ▪Ansibleでコード化

    •CentOS6 → Amazon Linuxで再構築 ◦ミドルウェアのバージョンが最新に ◦EBS最適化 ◦拡張ネットワーキング ◦Magnetic → SSD 負荷、レスポンス改善の取り組み アプリケーションサーバー
  17. 2018/2/20 TechPlay 34 インデックス変更前後のクエリ速度比較スクリプト •ランサーズの各画面で流れるクエリログをスクリプト化 ◦インデックスの変更前後でレスポンス値を比較 $ ./sql_measure.sh help_beginner 62

    mypage_experience 19 mypage_menu 18 mypage_profile 752 mypage_portfolio_lists 118 … profile_search 38 skill 69 top 17168 … user_login 63 work_create_expert 13 work_create_start 30 work_competition_logo 14 work_search 45 work_search_logo 107 work_search_all_budgetfrom 118 work_search_all_deadline 47 work_search_all_started 49 work_search_business 253 work_search_design 341 work_search_media 131 work_search_system 195 work_search_task 312 work_search_translation 94 work_search_web 270 work_search_writer 187 … インデックス削除後に 悪化するクエリ
  18. 2018/2/20 TechPlay 35 インデックスチューニングの具体例 •インデックス対象カラムの置き換え ◦作成日時(created)でのソートをidソートに置き換え ▪CakePHPは各テーブルにidがつく(Primary Key) ▪createdのソート順とidのソート順は基本的に一致する •カーディナリティの低いインデックスの見直し

    ◦例えば削除フラグ(deleted)(カーディナリティ2) ▪deleted = 0のレコードが大多数 ▪deleted = 1の検索は滅多に行われない ◦複合インデックス ▪カーディナリティの低いカラムが先に来ているパターン •FORCE INDEXの利用 ◦一時的な手段として ▪定期的に観測が必要 +-----------------+---------------------------------------+--------------+---------------------+-------------+ | Table | Key_name | Seq_in_index | Column_name | Cardinality | +-----------------+---------------------------------------+--------------+---------------------+-------------+ | categorizations | PRIMARY | 1 | id | 12672606 | | categorizations | category_id | 1 | category_id | 29402 | | categorizations | categorization_type | 1 | categorization_type | 3600 | | categorizations | categorization_type_categorization_id | 1 | category_id | 154 | | categorizations | categorization_type_categorization_id | 2 | categorization_type | 6336303 | | categorizations | categorization_type_categorization_id | 3 | categorization_id | 3168151 | +-----------------+---------------------------------------+--------------+---------------------+-------------+
  19. 2018/2/20 TechPlay 42 データ取得作業の委譲 •SSH Tunnelingサーバー経由でPrivate VPCの参照用Readerに接続 ◦エンジニア以外の社員もSQLでデータ取得 EC2 Aurora

    Reader SSH Tunneling SQLクライアント 接続先:SSH Tunnelingサーバー 接続ポート:8025(任意に設定) $ ssh -N -f -p 22 -i /home/mysqluser/.ssh/ec2.id_rsa ec2- user@EC2のIPアドレス -g -L 8025:lancers001.xxx.ap- northeast-1.rds.amazonaws.com:3306 Lancers EC2 instance
  20. 2018/2/20 TechPlay 43 アクセスログのAthena対応 App S3 ELB App EC2 instance

    Log EC2 EC2 instance Amazon Athena time:2018-02-15T11:38:53+09:00 server_addr:10.0.6.11 host:xxx.xxx.xxx.xxx method:GET reqsize:1624 uri:/mypage/ query: status:200 size:83 referer:https://www.lancers.jp/mypage/?ref=header_text ua:Mozilla/5.0 (Windows NT 6.1; Trident/7.0; rv:11.0) like Gecko forwardedfor:180.63.228.57 reqtime:0.080 apptime:0.080 user_id:1701012 alternative_id:- timecard_env:- { "time":"2018-02-15T11:38:53+09:00 ", "server_addr":"10.0. 6.11", "host":"xxx.xxx.xxx.xxx", "method":"GET", "reqsize":"1624", "uri":"/mypage/ ", "query":"", "status":"200", "size":“83", "referer":"https://www.lancers.jp/mypage/?ref=header_text ", "ua":"Mozilla/5.0 (Windows NT 6.1; Trident/7.0; rv:11.0) like Gecko forwardedfor:180.63.228.57 reqtime:0.278 ", "forwardedfor":"111.239.118.99", "reqtime":"0.080", "apptime":"0.080", "user_id":"1701012", "alternative_id":"-", "timecard_env":"-" } •Nginxログをタグ付きのフォーマットに ◦解析しやすい形式に変更 •td-agentでlogサーバーに変更 ◦JSON形式でS3に格納 ▪AthenaでSQLアクセス可能に SQLでアクセス可能 User Analyst
  21. 2018/2/20 TechPlay 46 ランサーズ開発環境の歴史(2008 ~ 2010) •開発人数:2人 •PC環境 ◦Windowsデスクトップ •開発環境

    ◦Linuxサーバーに直接ログイン ▪CentOS •開発ツール ◦ソース管理:SVN ◦直接ログインしてVimで開発
  22. 2018/2/20 TechPlay 47 ランサーズ開発環境の歴史(2011 ~ 2013) •開発人数:4人~10人 •PC環境 ◦Windowsデスクトップ ◦デザイナーはMac

    •開発環境 ◦社内開発サーバー(VMWare ESXi) •開発ツール ◦ソース管理:SVN ◦直接ログインしてVimで開発 ◦ssh経由でIDEを使う人も
  23. 2018/2/20 TechPlay 48 ランサーズ開発環境の歴史(2014 ~ 2015) •開発人数:10人~20人 •PC環境 ◦Windowsデスクトップ ◦エンジニアもMacに移行し始める

    •開発環境 ◦VirtualBox + Vagrant ◦Ansibleで個人PC内に開発環境を構築 ▪アプリチームで管理 •開発ツール ◦ソース管理:SVN→Githubに移行 ◦PC上のエディタで開発 ▪VirtualBox共有フォルダ ◦PHP Stormでデバッグする人も
  24. 2018/2/20 TechPlay 49 ランサーズ開発環境の歴史(2016 ~ 2017) •開発人数:20人以上 •PC環境 ◦ほとんどMac ◦Windowsは数人

    •開発環境 ◦VirtualBox + Docker Toolbox ◦Dockerfile + Ansibleでコンテナ構築 ▪インフラチームで管理 ▪開発者は構築済のコンテナをpullするだけ •開発ツール ◦ソース管理:Github ◦PC上のエディタで開発 ▪VirtualBox共有フォルダ Dockerマウント ◦PHP Stormのデバッグも可能
  25. 2018/2/20 TechPlay 50 ランサーズ開発環境の歴史(2017 ~ ) •開発人数:20人以上 •PC環境 ◦Mac ◦Windows

    ◦Linux •開発環境 ◦Docker For Mac(Windows) ◦Dockerfile + Ansibleでコンテナ構築 ◦インフラチームで管理 ▪開発者は構築済のコンテナをpullするだけ •開発ツール ◦ソース管理:Github ◦PC上のエディタで開発 ▪Dockerマウント or Docker Sync ◦PHP Stormのデバッグも可能
  26. 2018/2/20 TechPlay 51 Dockerへ移行した理由 192.168.33.11 HDD 50GB メモリ 2GB App(ランサーズ本体)

    Apache 2.2 (80) PHP 5.3 MySQL 5.6 (3306) Memcached(11211) •マシンリソース問題 ◦新規サービス開発の度にVMを作成
  27. 2018/2/20 TechPlay 52 Dockerへ移行した理由 192.168.33.11 HDD 50GB メモリ 2GB App(ランサーズ本体)

    Apache 2.2 (80) PHP 5.3 MySQL 5.6 (3306) Memcached(11211) 192.168.33.12 HDD 50GB メモリ 1GB メッセージ(チャット) Nginx(3443) node.js(3001) Redis(6379) •マシンリソース問題 ◦新規サービス開発の度にVMを作成
  28. 2018/2/20 TechPlay 53 Dockerへ移行した理由 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) •マシンリソース問題 ◦新規サービス開発の度にVMを作成
  29. 2018/2/20 TechPlay 54 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) •マシンリソース問題 ◦新規サービス開発の度にVMを作成
  30. 2018/2/20 TechPlay 55 Dockerへ移行した理由 192.168.33.11 HDD 50GB メモリ 2GB App(ランサーズ本体)

    Apache 2.2 (80) PHP 5.3 MySQL 5.6 (3306) Memcached(11211) •VMを1つにまとめる
  31. 2018/2/20 TechPlay 56 Dockerへ移行した理由 192.168.33.11 HDD 50GB メモリ 2GB App(ランサーズ本体)

    Apache 2.2 (80) PHP 5.3 MySQL 5.6 (3306) Memcached(11211) メッセージ(チャット) Nginx(3443) node.js(3001) Redis(6379 •VMを1つにまとめる
  32. 2018/2/20 TechPlay 57 Dockerへ移行した理由 192.168.33.11 HDD 50GB メモリ 2GB App(ランサーズ本体)

    Apache 2.2 (80) PHP 5.3 MySQL 5.6 (3306) Memcached(11211) メッセージ(チャット) Nginx(3443) node.js(3001) Redis(6379) WordPress Apache 2.4(80) PHP 5.5 MySQL 5.6(3306) •VMを1つにまとめる ◦バージョン混在の問題 ◦言語別、バージョン別に環境が欲しい
  33. 2018/2/20 TechPlay 58 Vagrant + Ansible時代の問題点 •構築に時間がかかる ◦PHP、MySQLのビルド時間:1.5時間 ◦MySQLのインポート時間:2.5時間以上 •構成更新時の問題

    ◦Appサーバーに新しいミドルウェアを追加 ▪Ansible PlaybookにPRを投げる •誰が検証するの? ◦検証中は開発できない ◦再構築も時間がかかる(元に戻らないリスクも) •誰もPlaybookを更新しなくなる ◦更新差分は手動でカバー ◦原因不明のエラーがさらに増える •Windows環境での構築が不安定 ◦Virtualbox、Vagrant、Ansibleのバージョン相性がシビア ▪成功率50%以下 ◦Windowsユーザーが激減
  34. 2018/2/20 TechPlay 59 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に 各種コンテナを配置
  35. 2018/2/20 TechPlay 60 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 リバースプロキシ データ入り
  36. 2018/2/20 TechPlay 61 Docker移行の方針 EC2 MySQLデータ 開発用データ App Ansible WordPress

    MySQL WebSocket WordPress App WebSocket MySQL Playbook docker push docker pull docker build Amazon ECR •構築に時間をかけない ◦コンテナをpullするだけで完了 コンテナは インフラチームが構築 アプリチームは コンテナをpullするだけ
  37. 2018/2/20 TechPlay 64 リリースフロー EC2 App Deploy EC2 instance EC2

    Canaria App EC2 instance Developer •Githubにpush
  38. 2018/2/20 TechPlay 65 リリースフロー EC2 App Deploy EC2 instance EC2

    Canaria App EC2 instance Developer •Webデプロイシステムからリリース
  39. 2018/2/20 TechPlay 66 リリースフロー EC2 App Deploy EC2 instance EC2

    Canaria App EC2 instance Developer •DeployサーバーがGithubからpull
  40. 2018/2/20 TechPlay 67 リリースフロー EC2 App Deploy EC2 instance EC2

    Canaria App EC2 instance composer install Developer •composer installの実行 ◦開発用Appコンテナを起動
  41. 2018/2/20 TechPlay 68 リリースフロー EC2 App Deploy EC2 instance EC2

    Canaria App EC2 instance rsync Developer •カナリア環境にrsync ◦最終確認
  42. 2018/2/20 TechPlay 69 リリースフロー EC2 App Deploy EC2 instance EC2

    Canaria App EC2 instance rsync Developer •本番環境にrsync
  43. 2018/2/20 TechPlay 70 リリースシステム 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のキャッシュクリア
  44. 2018/2/20 TechPlay 74 新バージョンへの対応 •PHP、CakePHPのバージョンアップ ◦2017年から本格的に開始 ▪現在:PHP 5.3 + CakePHP

    1.3 ◦バージョンアップ手順 ▪Apache + mod_php → Nginx + PHP-FPM ▪CakePHP 1.3 → CakePHP 2.8 ▪PHP 5.3 → PHP 5.6 ▪CakePHP 2.8 → CakePHP 2.9 ▪PHP 5.6 → PHP 7 ▪CakePHP 2.9 → CakePHP 3 •MySQLのバージョンアップ ◦Aurora MySQL 5.6 → 5.7 ▪開発環境で検証中 •MySQLコンテナを5.7に更新 イマココ
  45. 2018/2/20 TechPlay 76 本番環境のDocker化、API化、マイクロサービス化、サーバーレス化 •本番環境のDocker化 ◦アプリエンジニアが開発、リリース、運用を全て行える仕組み ◦リリース時間の短縮が課題 •API化の促進 ◦言語に依存しないサービス運用環境 ◦開発スピードの改善

    ◦アプリチームの責任範囲を明確にする •マイクロサービス化 ◦モノリシックのまま膨れ上がったプロダクトを分割 •サーバーレスで済む機能は積極的にサーバーレス化 ◦運用工数の削減 ◦サーバー費用の削減 Amazon ECR Amazon ECS Amazon API Gateway AWS Lambda