Slide 1

Slide 1 text

コンテナ環境のKotlinアプリケーション を運用しよう ~ Google Cloudを使って ~ 2023/04/07 Server-Side Kotlin Meetup vol.8 『初オフラインLT大会!』 株式会社スリーシェイク佐藤慧太@SatohJohn

Slide 2

Slide 2 text

自己紹介 ● 佐藤慧太@SatohJohn ● 今年1月 株式会社スリーシェイク入社 ● SREとして、お客様の労苦を なくす活動に従事 ● 趣味は、嫁の観察、プログラミング ● 最近はGoogle Cloudの資格勉強

Slide 3

Slide 3 text

株式会社スリーシェイクについて 3 Copyright © 3-shake, Inc. All Rights Reserved.    xOps Plattform DesignOps IaaS DevOps / SRE RevOps (Revenue Ops) HR(Engineer Hiring) HROps Data Engineering DataOps Security DevSecOps SecOps 事業者が抱える セキュリティリスクを無くす 本格的な脆弱性診断を 無料で手軽に セキュリファイ Security 良いエンジニアに良い案件を フリーランスエンジニアに 「今よりいい条件」を リランス HR(Engineer Hiring) あらゆるサービスを連携する ハブになる クラウド型ETL/データパイプ ラインサービスの決定版 レコナー Data Engineering 日本のSREをリード SRE総合支援からセキュリティ 対策を全方位支援 スリーク SRE スリーシェイク = xOps領域のプラットフォーマーへ

Slide 4

Slide 4 text

「どこで」「何を」「どうやって」 調べていくかの取っ掛かりになってほしい 本日のスライドの目的 Kotlin書きやすいし、良さそうで 選んだけど運用ってどうやればいいの? https://furandon-pig.github.io/fpig_sample/hobby/bad_spiral/

Slide 5

Slide 5 text

Kotlinの運用難しい?

Slide 6

Slide 6 text

コンテナ環境における Kotlinの運用で必要なことは?

Slide 7

Slide 7 text

アプリケーションの計測、可視化

Slide 8

Slide 8 text

Kotlinの運用で必要なこと ● アプリケーションの計測と可視化が必要である ○ アプリケーションログやメトリクス ○ JVMのチューニングに必要なログ ● 可視化、計測しないと、なんとなくの判断で 障害や課題に対応することになる

Slide 9

Slide 9 text

Kotlinの運用で必要なこと ● アプリケーションの計測と可視化が必要である ○ アプリケーションログやメトリクス ○ JVMのチューニングに必要なログ ● 可視化、計測しないと、なんとなくの判断で 障害や課題に対応することになる

Slide 10

Slide 10 text

他の言語で書いた アプリケーションでも必要なこと

Slide 11

Slide 11 text

なんでJVMがコンテナ環境で運用が難しい (と思われている)のかの個人的見解 ● コンテナ環境の運用に慣れていない ○ 見たものをそのまま取ってこれない ■ コンテナ内のログの消失 ■ コンテナ内のアプリケーションと メトリクス取得のための exporterとの共存

Slide 12

Slide 12 text

なんでJVMがコンテナ環境で運用が難しい (と思われている)のかの個人的見解 ● コンテナ化=Cloud RunなどのServerlessで使うんでしょ? ○ そもそものJVMの起動スピードの問題 ○ 一定期間で停止するのでチューニングがそもそも難しいし 取る必要がない可能性もある ● そもそもJVMのログ解析、難しい

Slide 13

Slide 13 text

コンテナ化=Cloud Run などのServerless?

Slide 14

Slide 14 text

コンテナ化しているそもそもの理由 ● ステートレスな環境の作成して、各個人の実行環境の差異を減らす ● ポータビリティを高めて、様々な場所で実行できるようにする ● 環境を閉じ込めているので検証が楽 ○ JDKのバージョンアップにも対応しやすいできる

Slide 15

Slide 15 text

コンテナ化しているそもそもの理由 ● ステートレスな環境の作成して、各個人の実行環境の差異を減らす ● ポータビリティを高めて、様々な場所で実行できるようにする ● 環境を閉じ込めているので検証が楽 ○ JDKのバージョンアップにも対応しやすいできる メリットは多いよね!

Slide 16

Slide 16 text

じゃあ Google Cloudで やってみよう

Slide 17

Slide 17 text

前提 ● Spring Boot WebFlux + Kotlin ● GCEでDockerを建てて起動 ● 以下を利用する ○ Cloud Logging ○ Clout Monitoring ○ Cloud Profiler

Slide 18

Slide 18 text

Cloud Logging ● とりあえずログを流しておいて、フィルターして探る ○ 基本的にアプリケーションログはここに流してしまう ● 使えるユースケース ○ 何時に、何件ぐらい出ているのかの確認 ○ 作成したfilterをチーム内で共有して障害や検証時に素早く対象箇所を見つける

Slide 19

Slide 19 text

Cloud Logging(設定) ● docker run時に --log-driver=gcplogs をつけるだけ ○ logにラベルをつけたい場合は --log-opt logs=〇〇,△△ --label 〇〇=hoge --label △△=fuga https://docs.docker.com/config/containers/logging/gcplogs/ docker run \ --log-driver=gcplogs \ --log-opt labels=app,ver --label app=sskt --label ver=1 \ --name sskt imageName

Slide 20

Slide 20 text

Cloud Loggingの クエリ jsonPayload.instance.name ="sskt" jsonPayload.container.metadata.app ="sskt" logName="projects/projectId/logs/gcplogs-docker-driver" 右の例だと、 ● インスタンスの名前 ● コンテナのlabel ● ログの種類で絞れる サンプルのクエリもあるので 勉強できる log4jにおけるセキュリティ侵害 のチェック のパターンもある

Slide 21

Slide 21 text

Cloud Monitoring ● CPUやメモリの状態、JVMなどheapのデータをダッシュボード形式で 確認できる ● 閾値に対してアラートを設定できる ● 使えるユースケース ○ Prometheus形式でのログを受信する ○ SLO/SLIに設定した閾値を超えた場合に、アラートを送信する

Slide 22

Slide 22 text

Cloud Monitoring(設定方法) 1. GCEに対してOpsエージェントを追加する 2. Spring Boot Actuator + Micrometer prometheusを利用してログを出力する a. io.github.mweirauch:micrometer-jvm-extras を追加します i. レポジトリに https://central.sonatype.com/artifact/ を追加します @Bean fun processMemoryMetrics(): MeterBinder { return ProcessMemoryMetrics() } @Bean fun processThreadMetrics(): MeterBinder { return ProcessThreadMetrics() }

Slide 23

Slide 23 text

Cloud Monitoring(設定方法) 3. GCEの/etc/google-cloud-ops-agent/config.yaml に以下を追加する metrics: receivers: prometheus: type: prometheus config: scrape_configs: - job_name: 'app' scrape_interval: 5s metrics_path: /actuator/prometheus static_configs: - targets: ['localhost:80'] service: pipelines: prometheus_pipeline: receivers: - prometheus

Slide 24

Slide 24 text

Cloud Monitoringでの見え方(JVMのHeapやリクエストRateなどが見れる) 複雑なものはそこまで作れない grafana のhttps://grafana.com/grafana/dashboards/4701-jvm-micrometer/ の指標を利用

Slide 25

Slide 25 text

監視している値に対して、 閾値を設定し、閾値を超えたら通知でき る ● Slack ● PagerDuty などなど https://cloud.google.com/monitoring/ support/notification-options?hl=ja#pa gerduty アラートの設定

Slide 26

Slide 26 text

Cloud Profiler ● APM(Application Performance Management)の一つ ● 内部のアプリケーション内のメソッドの呼び出しのCPU時間などがわかる ○ Javaの場合は、Heapなども出てくる ○ 時間帯で区切って平均で出される ● 使えるユースケース ○ アプリケーションのパフォーマンスチューニング

Slide 27

Slide 27 text

Cloud Profiler(設定方法) 1. コンテナにProfilerエージェントをインストールする 2. Service Accountの.jsonを /root/.config/gcloud/ に配置する 3. アプリケーション起動時にProfilerを一緒に起動する java \ -agentpath:/opt/cprof/profiler_java_agent.so=-cprof_service=sskt,-logtostderr \ -jar myApp.jar

Slide 28

Slide 28 text

Cloud Profiler(Gradle Jib Pluginを使っている場合のパターン jib { from { image = "〇〇" //ここにprofilerエージェントを追加している想定 } to { image = "〇〇" } container { jvmFlags = ["-agentpath:/opt/cprof/profiler_java_agent.so=-cprof_service=sskt,-cprof_cpu_use_per_thread_timer s,-cprof_enable_heap_sampling,-logtostderr,-minloglevel=2"] creationTime = "USE_CURRENT_TIMESTAMP" } extraDirectories { paths { path { from = './auth' into = '/root/.config/gcloud/' includes = ['*.json'] } } } }

Slide 29

Slide 29 text

CPU時間だけでみるとこんな感じ

Slide 30

Slide 30 text

クリックして深堀りができる(そのメソッドの中で何が呼ばれているのか)

Slide 31

Slide 31 text

まとめ

Slide 32

Slide 32 text

まとめ ● コンテナが一般化してきた中でServerSide Kotlinの Google Cloudを使った運用について以下で対応できる ○ Cloud Logging ○ Cloud Monitoring ○ Cloud Profiler ○ 他にもCloud TraceやError Reportingなど 運用の手助けができます!

Slide 33

Slide 33 text

Kotlinの運用 できそうじゃない?

Slide 34

Slide 34 text

「運用する」と心の中で思ったならッ! その時スデに行動は終わっているんだッ!

Slide 35

Slide 35 text

参考 ● Cloud Logging ○ https://cloud.google.com/logging/docs/overview?hl=ja ● Cloud Monitoring ○ https://cloud.google.com/stackdriver/docs/solutions/agents/ops-agent/fleet-installation? hl=ja ● Cloud Profiler ○ https://cloud.google.com/profiler/docs/profiling-java?hl=ja

Slide 36

Slide 36 text

おわり