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
   

   View Slide

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

   View Slide

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
   

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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)
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide