Slide 1

Slide 1 text

多数のプロダクトを開発・運⽤するための ツール環境 March 17th, 2023 Matsumoto Hiroki Marketing Cloud Platform Department Rakuten Group, Inc.

Slide 2

Slide 2 text

2 Profile 松本宏紀 ( Matsumoto Hiroki ) • Reliability Engineering Team • Software Engineer • Joined Rakuten in 2020 • Published • OSS: Passenger Go Exporter • Presentation: デプロイメント⼿法を選択する ~ Flagger/Argo Rollouts ~ • GKE + Java + Cassandra → Ruby + Go + Kubernetes ( Private Cloud / AKS ) • Twitter : @hirokimatsumo13

Slide 3

Slide 3 text

3 Table of Contents 1. 扱っているプロダクト群 2. 運⽤環境 3. 開発環境 4. 今後

Slide 4

Slide 4 text

4 扱っているプロダクト群 楽天グループ全体で利⽤される様々なプラットフォームの開発・運⽤を担当。 ShortURL Platform ショートURL管理 Lottery Platform くじ管理 Questionnaire Platform アンケート管理 Video Platform 動画管理 SUSUMERU Platform SNS投稿管理 Campaign Application Tool キャンペーン管理 Digital Media Center 画像管理 +2 Products

Slide 5

Slide 5 text

5 扱っているプロダクト群 ShortURL Platform Lottery Platform Questionnaire Platform Video Platform SUSUMERU Platform Campaign Application Tool Kubernetes環境下で多数のサービスが稼働している状態。 Digital Media Center +2 Products Kubernetes Ruby Golang Kubernetes Ruby Kubernetes Ruby Kubernetes Ruby Kubernetes Ruby Kubernetes Ruby Golang Kubernetes PHP

Slide 6

Slide 6 text

6 運⽤環境 - Kubernetes Private Cloud Multi regionで構築。またPrivate Cloud環境を主軸に、部分的にはAzure (Azure Kubernetes Engine) を利⽤。 Azure <> Kubernetes Cluster <> Kubernetes Cluster Prometheus+ Grafana <> Kubernetes Cluster <> Kubernetes Cluster Prometheus + Grafana Elastic Cloud Slack PagerDuty Teams HashiCorp Vault

Slide 7

Slide 7 text

7 運⽤環境 - Kubernetes Cluster CPU Deployments Traffics 12 over 400 cpus over 50 over 6,000 req/sec

Slide 8

Slide 8 text

8 運⽤環境 – メンバー Senior Operators Middle Operators Junior Operators 2 3 2 各⾃が全てのプロダクトのインシデント対応、リリースなどを⾏なっている状態。 また運⽤メンバーは専任ではなく、全員がDevOpsとして開発も担当。

Slide 9

Slide 9 text

9 すごい⼤変だと思う

Slide 10

Slide 10 text

10 運⽤環境 – 楽に管理するために 複数クラスタ管理は⼤変 Logging / APMはKibana、MetricsはGrafanaで管理できているが、特定podだけ問題が発⽣、特定 nodeだけで問題が発⽣する場合がある。その場合、kubernetesの状況を確認したり、nodeの corden, drainすることもあるが正直Terminalでのクラスタ切り替えめんどくさい。 定常的には開発環境のクラスタを利⽤してるので複数のクラスタを同時に利⽤したい。

Slide 11

Slide 11 text

11 運⽤環境 – 楽に管理するために Tool 所感 Rancher Private Cloud環境においてはcluster admin権限をもっていないので 利⽤できない。 k9s 複数クラスタを扱いやすい。 でも、logsやexecで⾊々⽴ち上げて管理しようと思うと、ちょっと ⼤変。(でも素のkubectlで扱うよりは断然楽だし安全) Lens (OpenLens) GUIでとても使いやすい。バグっぽい動きをバージョンアップの都度 みせるが、圧倒的使いやすさ︕

Slide 12

Slide 12 text

12 運⽤環境 – Lens Unable to skip login page https://github.com/lensapp/lens/issues/5444 あるバージョンからログインが必須になった。 認証情報の連携や、クラスタ情報をどこか別のサーバーなどに送信されるのは避けたい。

Slide 13

Slide 13 text

13 運⽤環境 – Lens ⾃分でビルドしちゃう https://github.com/h-r-k-matsumoto/lens/releases https://github.com/h-r-k-matsumoto/lens/blob/release/main/.github/workflows/release.yaml Core部分 ( Open Lens)に関しては、ソースが公開されているので独⾃ビルドして認証部分が含まれ ていないビルドイメージを作成して利⽤。

Slide 14

Slide 14 text

14 運⽤環境 – Lens Remove in-tree extensions to help facilitate a more secure and faster booting lens https://github.com/lensapp/lens/pull/6775 あるバージョンからpodのメニューからShell、Attachが無くなった。

Slide 15

Slide 15 text

15 運⽤環境 – Lens ⾃分でカスタマイズしちゃう 6ed16da︓もう直接埋め込んでしまえと変更 https://github.com/h-r-k-matsumoto/lens-extension-menu ちゃんとした拡張モジュールとして作成。でも・・・ https://github.com/lensapp/lens/issues/6846 アンインストールできないバグなどがあった ( 6.4.0で修正予定 すでに修正済み)

Slide 16

Slide 16 text

16 運⽤環境 可⽤性を限りなく⾼める。⾃⽴的復旧環境を構築することが⼤事。 もっと扱えるプロダクトをスケールアウトできるようにしたい。 そのためには、⼿間が掛からない運⽤環境を⽬指さなければならない。 故障は発⽣する。すぐ調査〜復旧するためのツール環境の構築。 Metrics、Logging、Operationsそれぞれ⼀元管理できる環境だとやはり操作性は良い。 偶発的に発⽣するNodeの問題などに対処するためにはkubectlを楽に、且つ安全に扱える環境を構 築した⽅が良い。

Slide 17

Slide 17 text

17 開発環境 楽に環境構築を作りたい。あまり負荷がかからない環境で開発したい。 扱うプロダクトも多数あるので、個⼈の開発環境ではkindは利⽤せず、単純にアプリケーション開 発のみに焦点を当てている。 Individuals (Mac OS) Lima VS Code + Dev Container AppRepository Dockerfile compose.yaml .devcontainer ManifestsRepository manifest files CI/CD: GitHub Actions Staging

Slide 18

Slide 18 text

18 開発環境 Lima https://lima-vm.io/ 以前はDocker Desktopを使っていたがライセンス変更に伴い、LimaによるLinux仮想環境に移⾏。 Docker⽤環境構築の例( docker.yaml )もあるので、容易に利⽤できる。 v0.14.0からはVirtualization frameworkがサポートされた。( リリースバイナリとして利⽤できたの は実質使えたのはv0.14.1から︖)

Slide 19

Slide 19 text

19 開発環境 Macでファイルアクセスが遅い問題 Rspecの実⾏で起動時に1分以上かかる場合があった。 恐らくvolume mountしているファイルが多いと、ものすごく時間がかかる︖ ※各個⼈の環境差異もある 個⼈的には下記を留意することで遅い問題は回避できてそう。 • Volume mountするのは最⼩限に • Virtualization Frameworkを利⽤する volumes: -.:/rails:cached -../framework:/framework:cache

Slide 20

Slide 20 text

20 開発環境 VS Code + Dev Container https://code.visualstudio.com/docs/devcontainers/containers とにかくPCに⾊々インストールするのが嫌。バージョンアップも管理するのも嫌。 全部コンテナの中に詰め込んでしまう。 必要なサービス ( MySQL, Redis ) 周りも全てコンテナ化。 後はroot権限を必要とするような環境構築を⾏わない。hosts 書き換えなどはOpsも担当するメン バーにとってはかなり危険な⾏為。環境毎の設定の⽤意や、DockerのNetwork aliasにてコンテナ、 およびdocker networkに閉じられたネットワーク空間で安全に開発することができる。

Slide 21

Slide 21 text

21 開発環境 インストール・設定が必要なものは最⼩限に。 OS依存部分はOSのUpgradeによって動かなくなることも度々ある。 また、DevOpsとして⾃⾝のネットワーク環境に変更を加えてしまうもの(/etc/hostsの書き換えなど) は、かなり危険。 コンテナ環境、およびコンテナのNetwork (+alias)に閉じられた空間で開発した⽅が安全。 ホストOSに依存するものは原則Lima + Docker + VSCodeのみ。Golangなどはインストールしていな い。

Slide 22

Slide 22 text

22 今後 30分でセットアップ完了に。 新規参画メンバーやPC交換時、セットアップ作業が無いと⾔えるほど楽な状態にしたい。 Office 365 ( like Google workspace)のように、全てWebで完結する世界を⽬指す。 運⽤環境 • まだ⾃分たちの要件に合うようなツールは⾒つからず・・・。 開発環境 • GitHub Enterprise + Codespaces Enterprise Cloudのみ。GitHub Enterprise未対応なので利⽤できず • Gitpod Dedicated ( Self Hosted ) • まだearly access。要アーキテクチャ確認

Slide 23

Slide 23 text

No content