sue445とOSSと社内ツール #subcul_dev

Slide 1

Slide 1 text

sue445とOSSと社内ツールサブカル業界Developers 勉強会 Vol.4 #subcul_dev pixiv Inc. sue445 2023.03.17

Slide 2

Slide 2 text

2 自己紹介 ● Go Sueyoshi a.k.a sue445 ● 2018年ピクシブ株式会社入社 ● インフラ部所属 ● OSS開発歴: 10年以上 sue445

Slide 3

Slide 3 text

3 最近のお仕事 (AWS, GCP) ● Organization Owner ● Solution Architect ○ AWS Certiﬁed 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

Slide 4

Slide 4 text

4 最近のお仕事 (その他) ● github.com/pixiv Organization Owner ● 社内ツールの運用（今日のメイン） ○ GitLab, Sentry ● 採用関係の手伝い ● 諸々雑用 sue445

Slide 5

Slide 5 text

5 最近の推し事 ● プリキュアシリーズ ● プリティーシリーズ(プリティーリズム/プリパラ/キラッとプリ☆チャン/ワッチャプリマジ/KING OF PRISM) ● 【重要】プリキュアシリーズ != プリティーシリーズ sue445

Slide 6

Slide 6 text

6 https://github.com/sue445 ● Publicなリポジトリが300個くらい ● うち、アクティブにメンテしてる（定期的に Dependabotでライブラリを最新にしたりnightlyビルドを実行している）OSSが80個くらい ● 自分にとってのOSSは「盆栽活動」 sue445

Slide 7

Slide 7 text

7 sue445 ● https://commits.top/japan.html や https://github.com/gayanvoice/top-github-users /blob/main/markdown/public_contributions/jap an.md で見ると日本国内だと上から20位前後にはいるっぽい

Slide 8

Slide 8 text

8 [CM] 今後の登壇予定 ● 2023/05/11～13: RubyKaigi 2023 at 松本市 ○ https://rubykaigi.org/2023/ sue445

Slide 9

Slide 9 text

● sue445が運用しているOSSの社内ツール ● sue445謹製の雑な社内ツールのOSS ● sue445が社内ツールをOSSとして公開する時に考えていること 9 アジェンダ

Slide 10

Slide 10 text

● ピクシブ社内にはsue445が開発や運用している社内ツールがたくさんある ● 社内ツールであってもOSSにしておいといた方が後々助かることが多い ● ウェブアプリケーションをOSSとして配布する場合、Dockerイメージとして配布するのが便利 10 最初にまとめ

Slide 11

Slide 11 text

● sue445が運用しているOSSの社内ツール ● sue445謹製の雑な社内ツールのOSS ● sue445が社内ツールをOSSとして公開する時に考えていること 11 アジェンダ

Slide 12

Slide 12 text

社内全体だとたくさんのOSSを利用しているのだが、sue445が運用しているものはこの2つ 1. GitLab 2. Sentry 12 sue445が運用しているOSSの社内ツール

Slide 13

Slide 13 text

● 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

Slide 14

Slide 14 text

● 【宣伝】約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

Slide 15

Slide 15 text

● 色々なアプリのエラーを収集して見やすくしたり通知するためのツール ○ 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

Slide 16

Slide 16 text

● 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

Slide 17

Slide 17 text

● sue445が運用しているOSSの社内ツール ● sue445謹製の雑な社内ツールのOSS ● sue445が社内ツールをOSSとして公開する時に考えていること 17 アジェンダ

Slide 18

Slide 18 text

業務に密接に関係はしていないが、無いとそれなりに困る社内ツールたちを厳選して紹介 1. gitpanda 2. tanuki_reminder 3. gitlabci-bundle-update-mr 4. emoy_webhook 5. 今日のアニメボット 18 sue445謹製の雑な社内ツールのOSS

Slide 19

Slide 19 text

● https://github.com/sue445/gitpanda ● https://inside.pixiv.blog/sue445/7256 ● GitLabのURLをSlackに貼り付けた時にいい感じに展開してくれるツール 19 1: gitpanda

Slide 20

Slide 20 text

● 開発言語: Go ● GitLab APIを利用しているため、GitLabと通信できる場所にバイナリやDockerイメージを置いて動かす想定 ● GitLabのGCP移行前はLambdaで動かしていてGCP移行後はCloud Runで動かしている ○ 余談: 前述のinside記事だとGKEで動かしているが、執筆後にCloud Runに移行した 20 1: gitpanda

Slide 21

Slide 21 text

● https://gitlab.com/sue445/tanuki_reminder ● マージされていないMergeRequestをSlackやChatWorkに通知するツール ● GitHubのScheduled remindersのGitLab版 ● 開発言語: Go 21 2: tanuki_reminder

Slide 22

Slide 22 text

● 小ネタ: GitLabでのユーザ名とSlackでのユーザ名が食い違うとSlackでメンションにならなくて困るのでユーザ名のマッピングを独自に持てるようにしてる ● ピクシブでは最初インターンでやってきて後に新卒入社することがよくあるのだが、 Slackアカウントを作り直した場合にインターン時代の Slackアカウントにメンションが吸われる事象がよく発生してるためユーザID指定でメンションできるようにしてる 22 2: tanuki_reminder

Slide 23

Slide 23 text

● https://gitlab.com/sue445/gitlabci-bundle-update-mr ● GitLab CI上でbundle updateしてMR(MergeRequest)を作るためのgem 23 3: gitlabci-bundle-update-mr

Slide 24

Slide 24 text

● 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

Slide 25

Slide 25 text

● https://github.com/sue445/emoy_webhook ● https://sue445.hatenablog.com/entry/2019/07/21/225436 ● Slackにemojiが追加された時にSlackのチャンネルに通知するためのツール 25 4: emoy_webhook

Slide 26

Slide 26 text

● 元々はHeroku appとして配布していたが、Herokuのプラン改定のタイミングでDockerise してDockerイメージとして配布するようにした ○ https://sue445.hatenablog.com/entry/2022/08/28/235754 ● 社内だとCloud Runで動かしている 26 4: emoy_webhook

Slide 27

Slide 27 text

● 余談: Slackにemojiを1つ追加した時にSlackからのイベントがwebhookに複数飛んでくることがあって、多重通知防止のためのキャッシュとして RedisやFirestoreが使えるようにしている ○ Heroku時代は最低スペックだとRedisが無料で使えたのだが、GCPだとCloud Memorystore for Redisが最低スペックであっても結構高いので (月46.8ドル)、 Firestore対応することでほぼ無料で運用できるようにしている 27 4: emoy_webhook

Slide 28

Slide 28 text

● https://github.com/sue445/today_anime ● https://inside.pixiv.blog/sue445/5647 ● Slackの #z-anime チャンネル（アニメ系の雑談チャンネル）で動かしているボット 28 5: 今日のアニメボット

Slide 29

Slide 29 text

● sue445が運用しているOSSの社内ツール ● sue445謹製の雑な社内ツールのOSS ● sue445が社内ツールをOSSとして公開する時に考えていること 29 アジェンダ

Slide 30

Slide 30 text

1. OSSにすべきかどうか 2. 配布形式 30 sue445が社内ツールをOSSとして公開する時に考えていること

Slide 31

Slide 31 text

● 社内ツールであっても積極的に OSSにすべき ○ 社内のリポジトリにしか無いと、転職した時にそのツールが使えなくて困る ■ 前職時代に作ったOSSを現職に導入した事例もいくつかある ○ OSSにしておけば自分で機能を実装しなくても利用者が PRを送ってくれる ● 今までの経験上、社内で動かしてるものを後から OSSにするよりも、最初からOSSにしておいて社内に導入する方が楽なことが多かった ● 会社にOSS活動に関するガイドラインがあればそれに従う 31 1: OSSにすべきかどうか

Slide 32

Slide 32 text

● 個人リポジトリで運用するか、会社 orgのリポジトリで運用するかはケースバイケース ○ 会社orgでリポジトリを作ってもリポジトリをメンテするチームがいなければメンテナが辞めた時にメンテされなくなる ○ メンテナ退職後にPullRequestやIssueが飛んできた場合に誰がそれを見るのかという問題 ● 会社として責任持ってメンテする気持ちがなければ個人リポジトリかその OSS専用のorgでいいと思う。（個人の感想です） 32 1: OSSにすべきかどうか

Slide 33

Slide 33 text

● この辺は社内ツールに限った話じゃないです ● ライブラリであればその言語に応じた場所で配布すればいい ○ 例）Rubyのgemなら https://rubygems.org/ ● しかし、ウェブアプリケーションの配布は考えることが多くて難しい 33 2: 配布形式

Slide 34

Slide 34 text

1. ソースコードのみ配布 2. ウェブアプリをパッケージにして配布 3. 実行環境含めて配布 34 2: 配布形式

Slide 35

Slide 35 text

● GitHubのリポジトリのみ公開するパターン ○ CI上で動くツールならこれでもいい ● メリット ○ 公開する側は簡単 ● デメリット ○ 利用する側は初期セットアップやバージョンアップに追従するのが大変 ○ アプリケーションの依存（aptやyumなどのパッケージなど）は自分でインストールが必要 ○ 実際にサーバ側で動かす時のdaemonizeやdeployの部分もケアされてないことが多いので自作する必要がある 35 1: ソースコードのみ配布

Slide 36

Slide 36 text

● 最近だとDockerイメージにしてDocker Hubなどで配布するのが主流 ○ Goでビルド済のスタンドアロンバイナリをリポジトリの releasesで配布 ● メリット ○ 利用者はdocker pullやwgetするだけで利用可能 ○ Dockerはエコシステムが充実してるので deployやdaemonize周りを自作しなくていいことが多い ● デメリット ○ 実行環境は自分で用意する必要がある 36 2: ウェブアプリをパッケージにして配布

Slide 37

Slide 37 text

● Dockerコンテナの実行環境は色々あるが、個人的なおすすめは GCPのCloud Run ● AWSであればApp Runnerよさそうだけど使ったことがない ● AWS Lambdaも悪くないのだが、Lambdaで動かすDockerイメージにはAWSで動かすためのパッケージを入れる必要があるのがちょっとネック 37 2: ウェブアプリをパッケージにして配布

Slide 38

Slide 38 text

● アプリケーションコードやDockerﬁleは普通に書けばいい ○ 手元でビルドしてdocker runで動作確認できたらCloud Runでもだいたい動く ● 環境構築が楽 ○ Dockerイメージさえ作れば gcloud run deployや google_cloud_run_service (Terraform)だけでアプリケーション、ログ、ロードバランサー、ウェブからアクセスできるURLが一式作成される 38 Cloud Runのメリット

Slide 39

Slide 39 text

● ちょっとしたウェブアプリであればほぼ無料で運用できる ● GCPだと他にAppEngine (Flexible Edition)でもDockerイメージを動かすことができるが、料金体系がちょっと違うのでCloud Runがおすすめ ○ AppEngine: 一度起動したインスタンスは最低 15分間起動するため、その分の費用が発生する ○ Cloud Run: 100ミリ秒単位での課金 ○ リクエスト数が少ないアプリの場合、 Cloud Runの方がコスパがいい 39 Cloud Runのメリット

Slide 40

Slide 40 text

● 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)

Slide 41

Slide 41 text

● GHCR(GitHub Container Registry)などのGCP外のDockerイメージをGCPで動かしたい場合には下記が必要 ○ GCEのVM上でdocker run / docker compose up / Swarmなど ○ GKE 41 Cloud Runのデメリット(OLD)

Slide 42

Slide 42 text

● アプリケーション本体のDockerイメージ以外にも必要なミドルウェアがたくさんある場合、 Kubernetesで動かすためにHelm chartもセットで配布する選択肢もある ○ GitLabやSentryがこの方式 42 2: ウェブアプリをパッケージにして配布

Slide 43

Slide 43 text

● 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: 実行環境含めて配布

Slide 44

Slide 44 text

● ピクシブ社内にはsue445が開発や運用している社内ツールがたくさんある ● 社内ツールであってもOSSにしておいた方が後々助かることが多い ● ウェブアプリケーションをOSSとして配布する場合、Dockerイメージとして配布するのが便利 44 まとめ