sue445とOSSと社内ツール #subcul_dev

サブカル業界Developers 勉強会 Vol.4( https://subculturedev.connpass.com/event/275395/ )の発表資料です

Transcript

1. sue445とOSSと社内ツール サブカル業界Developers 勉強会 Vol.4 #subcul_dev pixiv Inc. sue445 2023.03.17
2. 2 自己紹介 • Go Sueyoshi a.k.a sue445 • 2018年 ピクシブ株式会社 入社 • インフラ部所属 • OSS開発歴: 10年以上 sue445
3. 3 最近のお仕事 (AWS, GCP) • Organization Owner • Solution Architect ◦ AWS Certified Solutions Architect – Professional ▪ https://www.credly.com/badges/07f0 df7e-3479-463a-8c3e-6d6e34320dc8 ◦ Google Cloud Professional Cloud Architect ▪ https://www.credential.net/9643f19d- 5584-40b6-a330-5b966a26f310 sue445
4. 4 最近のお仕事 (その他) • github.com/pixiv Organization Owner • 社内ツールの運用（今日のメイン） ◦ GitLab, Sentry • 採用関係の手伝い • 諸々雑用 sue445
5. 5 最近の推し事 • プリキュアシリーズ • プリティーシリーズ(プリティーリズム/プリパラ/キラッ とプリ☆チャン/ワッチャプリマジ/KING OF PRISM) • 【重要】プリキュアシリーズ != プリティーシリーズ sue445
6. 6 https://github.com/sue445 • Publicなリポジトリが300個くらい • うち、アクティブにメンテしてる（定期的に Dependabotでライブラリを最新にしたりnightlyビル ドを実行している）OSSが80個くらい • 自分にとってのOSSは「盆栽活動」 sue445
7. 7 sue445 • https://commits.top/japan.html や https://github.com/gayanvoice/top-github-users /blob/main/markdown/public_contributions/jap an.md で見ると日本国内だと上から20位前後には いるっぽい
8. 8 [CM] 今後の登壇予定 • 2023/05/11～13: RubyKaigi 2023 at 松本市 ◦ https://rubykaigi.org/2023/ sue445
9. • sue445が運用しているOSSの社内ツール • sue445謹製の雑な社内ツールのOSS • sue445が社内ツールをOSSとして公開する時に考えていること 9 アジェンダ
10. • ピクシブ社内にはsue445が開発や運用している社内ツールがたくさんある • 社内ツールであってもOSSにしておいといた方が後々助かることが多い • ウェブアプリケーションをOSSとして配布する場合、Dockerイメージとして配布するのが便 利 10 最初にまとめ
11. • sue445が運用しているOSSの社内ツール • sue445謹製の雑な社内ツールのOSS • sue445が社内ツールをOSSとして公開する時に考えていること 11 アジェンダ
12. 社内全体だとたくさんのOSSを利用しているのだが、sue445が運用しているものはこの2つ 1. GitLab 2. Sentry 12 sue445が運用しているOSSの社内ツール
13. • gitのリポジトリをホスティングするツール ◦ https://about.gitlab.com/ja-jp/ ◦ https://gitlab.com/gitlab-org/gitlab • 似たような立ち位置のツールだと GitHub Enterprise Server (GHE:S) • GitLab本体がRailsで、その周辺のいくつかのミドルウェアは Goで作られている • SaaS版(https://gitlab.com)とSelf-managed版があって、ピクシブではSelf-managed版 を利用している • 一部を除いて業務利用しているコードはほぼ全て社内の GitLabにある ◦ OSSはGitHub.comを利用 13 1: GitLab
14. • 【宣伝】約1年かけてGitLabをオンプレミス環境からGCPに完全移行した記事を先日公開し ました ◦ 前編: https://inside.pixiv.blog/2022/11/29/110000 ◦ 中編: https://inside.pixiv.blog/2022/12/20/113000 ◦ 後編: https://inside.pixiv.blog/2022/12/22/110000 ◦ 計4万文字 • 全部読むのに1時間くらいかかると思うのでこの会が終わってから読んでください 14 1: GitLab
15. • 色々なアプリのエラーを収集して見やすくしたり通知するためのツール ◦ https://github.com/getsentry/sentry • 似たような立ち位置のツールだと Rollbar, Errbit辺り • SaaS版(https://sentry.io)とSelf-Hosted版がある • ピクシブではオンプレミス環境で Self-Hosted版を動かしていて、2020年にGKEに移行した • 詳細: https://speakerdeck.com/sue445/migrated-to-gke-sentry-number-pixivdevmeetup 15 2: Sentry
16. • Sentry本体はPythonとRustで作られていて、その他KafkaやClickHouseなどのミドルウェ アも必要 • Kubernetesであれば https://github.com/sentry-kubernetes/charts で必要なミドルウェ ア含めてまとめて構築できる ◦ Helm chartを利用するにあたって必要なパラメータを渡せず困ったので 10個くらい パッチを投げた ◦ https://github.com/sentry-kubernetes/charts/pulls?q=is%3Apr+author%3Asue 445+is%3Aclosed 16 2: Sentry
17. • sue445が運用しているOSSの社内ツール • sue445謹製の雑な社内ツールのOSS • sue445が社内ツールをOSSとして公開する時に考えていること 17 アジェンダ
18. 業務に密接に関係はしていないが、無いとそれなりに困る社内ツールたちを厳選して紹介 1. gitpanda 2. tanuki_reminder 3. gitlabci-bundle-update-mr 4. emoy_webhook 5. 今日のアニメボット 18 sue445謹製の雑な社内ツールのOSS
19. • https://github.com/sue445/gitpanda • https://inside.pixiv.blog/sue445/7256 • GitLabのURLをSlackに貼り付けた時にいい感じに展開してくれるツール 19 1: gitpanda
20. • 開発言語: Go • GitLab APIを利用しているため、GitLabと通信できる場所にバイナリやDockerイメージを 置いて動かす想定 • GitLabのGCP移行前はLambdaで動かしていてGCP移行後はCloud Runで動かしている ◦ 余談: 前述のinside記事だとGKEで動かしているが、執筆後にCloud Runに移行した 20 1: gitpanda
21. • https://gitlab.com/sue445/tanuki_reminder • マージされていないMergeRequestをSlackやChatWorkに通知するツール • GitHubのScheduled remindersのGitLab版 • 開発言語: Go 21 2: tanuki_reminder
22. • 小ネタ: GitLabでのユーザ名とSlackでのユーザ名が食い違うとSlackでメンションにならな くて困るのでユーザ名のマッピングを独自に持てるようにしてる • ピクシブでは最初インターンでやってきて後に新卒入社することがよくあるのだが、 Slackア カウントを作り直した場合にインターン時代の Slackアカウントにメンションが吸われる事象 がよく発生してるためユーザID指定でメンションできるようにしてる 22 2: tanuki_reminder
23. • https://gitlab.com/sue445/gitlabci-bundle-update-mr • GitLab CI上でbundle updateしてMR(MergeRequest)を作るためのgem 23 3: gitlabci-bundle-update-mr
24. • https://github.com/masutaka/circleci-bundle-update-pr のGitLab版 • 開発言語: Ruby • 社内だと他に https://github.com/dependabot/dependabot-script や https://github.com/renovatebot/renovate も併用してる 24 3: gitlabci-bundle-update-mr
25. • https://github.com/sue445/emoy_webhook • https://sue445.hatenablog.com/entry/2019/07/21/225436 • Slackにemojiが追加された時にSlackのチャンネルに通知するためのツール 25 4: emoy_webhook
26. • 元々はHeroku appとして配布していたが、Herokuのプラン改定のタイミングでDockerise してDockerイメージとして配布するようにした ◦ https://sue445.hatenablog.com/entry/2022/08/28/235754 • 社内だとCloud Runで動かしている 26 4: emoy_webhook
27. • 余談: Slackにemojiを1つ追加した時にSlackからのイベントがwebhookに複数飛んでくる ことがあって、多重通知防止のためのキャッシュとして RedisやFirestoreが使えるようにし ている ◦ Heroku時代は最低スペックだとRedisが無料で使えたのだが、GCPだとCloud Memorystore for Redisが最低スペックであっても結構高いので (月46.8ドル)、 Firestore対応することでほぼ無料で運用できるようにしている 27 4: emoy_webhook
28. • https://github.com/sue445/today_anime • https://inside.pixiv.blog/sue445/5647 • Slackの #z-anime チャンネル（アニメ系の雑談チャンネル）で動かしているボット 28 5: 今日のアニメボット
29. • sue445が運用しているOSSの社内ツール • sue445謹製の雑な社内ツールのOSS • sue445が社内ツールをOSSとして公開する時に考えていること 29 アジェンダ
30. 1. OSSにすべきかどうか 2. 配布形式 30 sue445が社内ツールをOSSとして公開する時 に考えていること
31. • 社内ツールであっても積極的に OSSにすべき ◦ 社内のリポジトリにしか無いと、転職した時にそのツールが使えなくて困る ▪ 前職時代に作ったOSSを現職に導入した事例もいくつかある ◦ OSSにしておけば自分で機能を実装しなくても利用者が PRを送ってくれる • 今までの経験上、社内で動かしてるものを後から OSSにするよりも、最初からOSSにしてお いて社内に導入する方が楽なことが多かった • 会社にOSS活動に関するガイドラインがあればそれに従う 31 1: OSSにすべきかどうか
32. • 個人リポジトリで運用するか、会社 orgのリポジトリで運用するかはケースバイケース ◦ 会社orgでリポジトリを作ってもリポジトリをメンテするチームがいなければメンテナが 辞めた時にメンテされなくなる ◦ メンテナ退職後にPullRequestやIssueが飛んできた場合に誰がそれを見るのかとい う問題 • 会社として責任持ってメンテする気持ちがなければ個人リポジトリかその OSS専用のorgで いいと思う。（個人の感想です） 32 1: OSSにすべきかどうか
33. • この辺は社内ツールに限った話じゃないです • ライブラリであればその言語に応じた場所で配布すればいい ◦ 例）Rubyのgemなら https://rubygems.org/ • しかし、ウェブアプリケーションの配布は考えることが多くて難しい 33 2: 配布形式
34. 1. ソースコードのみ配布 2. ウェブアプリをパッケージにして配布 3. 実行環境含めて配布 34 2: 配布形式
35. • GitHubのリポジトリのみ公開するパターン ◦ CI上で動くツールならこれでもいい • メリット ◦ 公開する側は簡単 • デメリット ◦ 利用する側は初期セットアップやバージョンアップに追従するのが大変 ◦ アプリケーションの依存（aptやyumなどのパッケージなど）は自分でインストールが必 要 ◦ 実際にサーバ側で動かす時のdaemonizeやdeployの部分もケアされてないことが多 いので自作する必要がある 35 1: ソースコードのみ配布
36. • 最近だとDockerイメージにしてDocker Hubなどで配布するのが主流 ◦ Goでビルド済のスタンドアロンバイナリをリポジトリの releasesで配布 • メリット ◦ 利用者はdocker pullやwgetするだけで利用可能 ◦ Dockerはエコシステムが充実してるので deployやdaemonize周りを自作しなくてい いことが多い • デメリット ◦ 実行環境は自分で用意する必要がある 36 2: ウェブアプリをパッケージにして配布
37. • Dockerコンテナの実行環境は色々あるが、個人的なおすすめは GCPのCloud Run • AWSであればApp Runnerよさそうだけど使ったことがない • AWS Lambdaも悪くないのだが、Lambdaで動かすDockerイメージにはAWSで動かすた めのパッケージを入れる必要があるのがちょっとネック 37 2: ウェブアプリをパッケージにして配布
38. • アプリケーションコードやDockerfileは普通に書けばいい ◦ 手元でビルドしてdocker runで動作確認できたらCloud Runでもだいたい動く • 環境構築が楽 ◦ Dockerイメージさえ作れば gcloud run deployや google_cloud_run_service (Terraform)だけでアプリケーション、ログ、ロードバランサー、ウェブからアクセスでき るURLが一式作成される 38 Cloud Runのメリット
39. • ちょっとしたウェブアプリであればほぼ無料で運用できる • GCPだと他にAppEngine (Flexible Edition)でもDockerイメージを動かすことができるが、 料金体系がちょっと違うのでCloud Runがおすすめ ◦ AppEngine: 一度起動したインスタンスは最低 15分間起動するため、その分の費用 が発生する ◦ Cloud Run: 100ミリ秒単位での課金 ◦ リクエスト数が少ないアプリの場合、 Cloud Runの方がコスパがいい 39 Cloud Runのメリット
40. • GCPでホスティングされているDockerイメージ(Container Registry, Artifact Registry)しか 使えない • https://cloud.google.com/run/docs/release-notes#February_16_2023 🆕 ◦ > You can now deploy public container images from Docker Hub to Cloud Run. • ひゃっほおおおおおお！！！！！！！！！！！！！！！！ • 前述のinsideだとGitLab移行直後のPlantUMLはGKEで動かしていたが、先日Cloud Run へ移行した 40 Cloud Runのデメリット(OLD)
41. • GHCR(GitHub Container Registry)などのGCP外のDockerイメージをGCPで動かしたい 場合には下記が必要 ◦ GCEのVM上でdocker run / docker compose up / Swarmなど ◦ GKE 41 Cloud Runのデメリット(OLD)
42. • アプリケーション本体のDockerイメージ以外にも必要なミドルウェアがたくさんある場合、 Kubernetesで動かすためにHelm chartもセットで配布する選択肢もある ◦ GitLabやSentryがこの方式 42 2: ウェブアプリをパッケージにして配布
43. • Herokuの「Deploy to Heroku button」 ◦ https://devcenter.heroku.com/articles/heroku-button ◦ GitHubのリポジトリにあるボタンをクリックしたら Herokuの自分のアカウント上に同じ アプリをデプロイできて便利 • Cloud Run Button ◦ https://cloud.google.com/blog/ja/products/gcp/introducing-cloud-run-button- click-to-deploy-your-git-repos-to-google-cloud ◦ HerokuのやつのCloud Run版 • ベンダーロックインを気にしなければ便利 43 3: 実行環境含めて配布
44. • ピクシブ社内にはsue445が開発や運用している社内ツールがたくさんある • 社内ツールであってもOSSにしておいた方が後々助かることが多い • ウェブアプリケーションをOSSとして配布する場合、Dockerイメージとして配布するのが便 利 44 まとめ