ピクスタのエンジニアリングとCircleCI Yuichi Goto (@_yasaichi) January 16, 2020 @ CircleCI ユーザーコミュニティミートアップ#8

self.inspect ! Yuichi Goto ! @_yasaichi " yasaichi " ピクスタ株式会社 執行役員CTO兼開発部長 2

コーポレートサイトトップ: https://pixta.co.jp 3 [PR] ピクスタはクリエイティブプラットフォームを創る会社です

Agenda 4 1. ピクスタにおける技術の位置づけ 2. ピクスタにおけるCircleCI活用事例 3. まとめ

目指すエンジニアリング組織像 • あるべき姿: 経営課題の達成に必要な要求に対して、質の高いアウトプットを速く継続 的に出せている状態 • ギャップを埋めるためのアプローチ: 仮説検証サイクルを高速化し、不確実性を乗りこなせる組織を作る 5

ソフトウェア技術の位置づけ • 位置づけ: 仮説検証サイクルのボトルネックを解消する手段のひとつ • KPI: • サイクルタイム（コードを書き始めてからデプロイ可能になるまで） • 開発者1人あたりの1日のデプロイ件数 • MTTR（Mean Time To Recovery、平均修復時間） 6 こう自分に言い聞かせないと好きに技術を使ってしまう…

CI/CDパイプラインへの期待 • 高速な自動テストの実行によりコードの誤りにすぐ気づけるようにし、手戻り （≒サイクルタイム）を減らしたい • デプロイ作業の自動化・高速化により、気軽にリリースできるようにしたい • 任意時点の本番環境にすぐ切り戻せるようにし、障害を最小限に抑えたい 7 CI/CDパイプラインの構築・改善は広範な問題を解決できる

Agenda 8 1. ピクスタにおける技術の位置づけ 2. ピクスタにおけるCircleCI活用事例 3. まとめ

https://pixta.jp 9 事例1: PIXTA（デジタル素材のマーケットプレイス）の場合

PIXTAにおける課題と解決策 • 課題: 10年近い歴史のある"本体"アプリケーションの自動テストの実行に マシン一台だと数時間かかり、CIの結果を待たずにデプロイされてしまう • 解決策: 1. RRRSpec（by Cookpad）の導入による自動テストの並列分散実行 2. ↑のEOLにより、当時トライアルだったPerformanceプランを採用して CircleCIに移行し、並列実行はそのままに運用負荷の低減を実現 10 明らかにボトルネックだったとわかる

https://fotowa.com 11 事例2:fotowa（出張撮影プラットフォーム）の場合

fotowaにおける課題と解決策 • 課題: Kubernetes導入に伴い、自動テストが通ったらDockerイメージを ビルドしてクラスタにデプロイしたい（もちろん全て自動で） • 解決策: 1. Workflowsを使ってビルドジョブの後に`setup_remote_docker`で Dockerイメージをビルドし、ECRにpush 2. pushをフックにしてCodePipelineが起動し、EKSクラスタにデプロイ 12

補足: その他のマネージドCI/CDサービスの採用事例 • CodeBuild: デプロイ自動化のみ必要な場合（例: CMS）に利用 • GitHub Actions: https://github.com/pixta-dev/repository- mirroring-action を作り、GitHub → CodeCommitへのミラーに利用 13 CIは基本CircleCI、CD+αは各サービスで行う、という使い分け

Agenda 14 1. ピクスタにおける技術の位置づけ 2. ピクスタにおけるCircleCI活用事例 3. まとめ

まとめ • 速く継続的に経営課題を達成するために、エンジニアリング組織としては 仮説検証サイクルの高速化にフォーカスしている • 技術は仮説検証サイクルのボトルネックを解消する手段のひとつ • CI/CDパイプラインの構築・改善は広範な問題を解決でき、てこが効く • 用途に応じてCircleCIとその他マネージドサービスを使い分けている 15

ご清聴ありがとうございました 16