Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
コンテナ環境のKotlinアプリケーション を運用しよう _ Google Cloudを使って
Search
SatohJohn
April 07, 2023
Programming
0
160
コンテナ環境のKotlinアプリケーション を運用しよう _ Google Cloudを使って
2023/04/07 Server-Side Kotlin Meetup vol.8 『初オフラインLT大会!』での発表スライドです
SatohJohn
April 07, 2023
Tweet
Share
More Decks by SatohJohn
See All by SatohJohn
Workforce Identity を使った 権限管理で Cloud Run を動かしてみた
satohjohn
0
1
Gemini + Vertex AI を使って作業を自動化「していく」
satohjohn
0
26
Cloud_Run_GPU___Gemma_2_を使った_LLM_アプリケーション開発のススメ.pdf
satohjohn
0
2
Firebase Authenticationのセッション管理術
satohjohn
2
2k
お客様とすすめる_フロントエンドの技術支援.pdf
satohjohn
1
1.1k
GCPでのバッチ処理パターンを考えてみる
satohjohn
1
1.1k
GCPと連携してマスターデータ更新
satohjohn
0
180
Nuxt.js + Google App Engine でのアプリケーション開発の勘所
satohjohn
0
460
Other Decks in Programming
See All in Programming
A Journey of Contribution and Collaboration in Open Source
ivargrimstad
0
960
C++でシェーダを書く
fadis
6
4.1k
受け取る人から提供する人になるということ
little_rubyist
0
250
Remix on Hono on Cloudflare Workers
yusukebe
1
300
Quine, Polyglot, 良いコード
qnighy
4
650
シェーダーで魅せるMapLibreの動的ラスタータイル
satoshi7190
1
480
初めてDefinitelyTypedにPRを出した話
syumai
0
420
EMになってからチームの成果を最大化するために取り組んだこと/ Maximize team performance as EM
nashiusagi
0
100
ピラミッド、アイスクリームコーン、SMURF: 自動テストの最適バランスを求めて / Pyramid Ice-Cream-Cone and SMURF
twada
PRO
10
1.3k
subpath importsで始めるモック生活
10tera
0
310
flutterkaigi_2024.pdf
kyoheig3
0
150
Kaigi on Rails 2024 〜運営の裏側〜
krpk1900
1
230
Featured
See All Featured
4 Signs Your Business is Dying
shpigford
180
21k
[RailsConf 2023] Rails as a piece of cake
palkan
52
4.9k
Intergalactic Javascript Robots from Outer Space
tanoku
269
27k
Measuring & Analyzing Core Web Vitals
bluesmoon
4
130
How to train your dragon (web standard)
notwaldorf
88
5.7k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
329
21k
Being A Developer After 40
akosma
87
590k
StorybookのUI Testing Handbookを読んだ
zakiyama
27
5.3k
Why Our Code Smells
bkeepers
PRO
334
57k
5 minutes of I Can Smell Your CMS
philhawksworth
202
19k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
6
410
YesSQL, Process and Tooling at Scale
rocio
169
14k
Transcript
コンテナ環境のKotlinアプリケーション を運用しよう ~ Google Cloudを使って ~ 2023/04/07 Server-Side Kotlin Meetup
vol.8 『初オフラインLT大会!』 株式会社スリーシェイク佐藤慧太@SatohJohn
自己紹介 • 佐藤慧太@SatohJohn • 今年1月 株式会社スリーシェイク入社 • SREとして、お客様の労苦<Toil>を なくす活動に従事 •
趣味は、嫁の観察、プログラミング • 最近はGoogle Cloudの資格勉強
株式会社スリーシェイクについて 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領域のプラットフォーマーへ
「どこで」「何を」「どうやって」 調べていくかの取っ掛かりになってほしい 本日のスライドの目的 Kotlin書きやすいし、良さそうで 選んだけど運用ってどうやればいいの? https://furandon-pig.github.io/fpig_sample/hobby/bad_spiral/
Kotlinの運用難しい?
コンテナ環境における Kotlinの運用で必要なことは?
アプリケーションの計測、可視化
Kotlinの運用で必要なこと • アプリケーションの計測と可視化が必要である ◦ アプリケーションログやメトリクス ◦ JVMのチューニングに必要なログ • 可視化、計測しないと、なんとなくの判断で 障害や課題に対応することになる
Kotlinの運用で必要なこと • アプリケーションの計測と可視化が必要である ◦ アプリケーションログやメトリクス ◦ JVMのチューニングに必要なログ • 可視化、計測しないと、なんとなくの判断で 障害や課題に対応することになる
他の言語で書いた アプリケーションでも必要なこと
なんでJVMがコンテナ環境で運用が難しい (と思われている)のかの個人的見解 • コンテナ環境の運用に慣れていない ◦ 見たものをそのまま取ってこれない ▪ コンテナ内のログの消失 ▪ コンテナ内のアプリケーションと
メトリクス取得のための exporterとの共存
なんでJVMがコンテナ環境で運用が難しい (と思われている)のかの個人的見解 • コンテナ化=Cloud RunなどのServerlessで使うんでしょ? ◦ そもそものJVMの起動スピードの問題 ◦ 一定期間で停止するのでチューニングがそもそも難しいし 取る必要がない可能性もある
• そもそもJVMのログ解析、難しい
コンテナ化=Cloud Run などのServerless?
コンテナ化しているそもそもの理由 • ステートレスな環境の作成して、各個人の実行環境の差異を減らす • ポータビリティを高めて、様々な場所で実行できるようにする • 環境を閉じ込めているので検証が楽 ◦ JDKのバージョンアップにも対応しやすいできる
コンテナ化しているそもそもの理由 • ステートレスな環境の作成して、各個人の実行環境の差異を減らす • ポータビリティを高めて、様々な場所で実行できるようにする • 環境を閉じ込めているので検証が楽 ◦ JDKのバージョンアップにも対応しやすいできる メリットは多いよね!
じゃあ Google Cloudで やってみよう
前提 • Spring Boot WebFlux + Kotlin • GCEでDockerを建てて起動 •
以下を利用する ◦ Cloud Logging ◦ Clout Monitoring ◦ Cloud Profiler
Cloud Logging • とりあえずログを流しておいて、フィルターして探る ◦ 基本的にアプリケーションログはここに流してしまう • 使えるユースケース ◦ 何時に、何件ぐらい出ているのかの確認
◦ 作成したfilterをチーム内で共有して障害や検証時に素早く対象箇所を見つける
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
Cloud Loggingの クエリ jsonPayload.instance.name ="sskt" jsonPayload.container.metadata.app ="sskt" logName="projects/projectId/logs/gcplogs-docker-driver" 右の例だと、 •
インスタンスの名前 • コンテナのlabel • ログの種類で絞れる サンプルのクエリもあるので 勉強できる log4jにおけるセキュリティ侵害 のチェック のパターンもある
Cloud Monitoring • CPUやメモリの状態、JVMなどheapのデータをダッシュボード形式で 確認できる • 閾値に対してアラートを設定できる • 使えるユースケース ◦
Prometheus形式でのログを受信する ◦ SLO/SLIに設定した閾値を超えた場合に、アラートを送信する
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() }
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
Cloud Monitoringでの見え方(JVMのHeapやリクエストRateなどが見れる) 複雑なものはそこまで作れない grafana のhttps://grafana.com/grafana/dashboards/4701-jvm-micrometer/ の指標を利用
監視している値に対して、 閾値を設定し、閾値を超えたら通知でき る • Slack • PagerDuty などなど https://cloud.google.com/monitoring/ support/notification-options?hl=ja#pa
gerduty アラートの設定
Cloud Profiler • APM(Application Performance Management)の一つ • 内部のアプリケーション内のメソッドの呼び出しのCPU時間などがわかる ◦ Javaの場合は、Heapなども出てくる
◦ 時間帯で区切って平均で出される • 使えるユースケース ◦ アプリケーションのパフォーマンスチューニング
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
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'] } } } }
CPU時間だけでみるとこんな感じ
クリックして深堀りができる(そのメソッドの中で何が呼ばれているのか)
まとめ
まとめ • コンテナが一般化してきた中でServerSide Kotlinの Google Cloudを使った運用について以下で対応できる ◦ Cloud Logging ◦
Cloud Monitoring ◦ Cloud Profiler ◦ 他にもCloud TraceやError Reportingなど 運用の手助けができます!
Kotlinの運用 できそうじゃない?
「運用する」と心の中で思ったならッ! その時スデに行動は終わっているんだッ!
参考 • 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
おわり