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
190
コンテナ環境の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
Gemini Enterprise を恐れない - Securityと監査-
satohjohn
0
28
進化の早すぎる生成 AI と向き合う
satohjohn
0
160
お前も Gemini CLI extensions を作らないか?
satohjohn
0
110
検索システムにおけるセキュリティ
satohjohn
0
77
Feature Flag 開発を標準化し、加速させる OpenFeature を導入する
satohjohn
4
2.4k
ADK Java が出たので AI Agent を作ろう
satohjohn
0
160
NotebookLM + Agentspace を使った(開発)体験
satohjohn
1
840
Open Feature 面白いぞ
satohjohn
0
110
Workforce Identity を使った 権限管理で Cloud Run を動かしてみた
satohjohn
0
770
Other Decks in Programming
See All in Programming
高単価案件で働くための心構え
nullnull
0
170
DartASTとその活用
sotaatos
2
150
Micro Frontendsで築いた 共通基盤と運用の試行錯誤 / Building a Shared Platform with Micro Frontends: Operational Learnings
kyntk
0
1.6k
JEP 496 と JEP 497 から学ぶ耐量子計算機暗号入門 / Learning Post-Quantum Crypto Basics from JEP 496 & 497
mackey0225
2
500
Herb to ReActionView: A New Foundation for the View Layer @ San Francisco Ruby Conference 2025
marcoroth
0
200
Stay Hacker 〜九州で生まれ、Perlに出会い、コミュニティで育つ〜
pyama86
2
2.8k
[堅牢.py #1] テストを書かない研究者に送る、最初にテストを書く実験コード入門 / Let's start your ML project by writing tests
shunk031
11
6.2k
アーキテクチャと考える迷子にならない開発者テスト
irof
9
3.4k
TVerのWeb内製化 - 開発スピードと品質を両立させるまでの道のり
techtver
PRO
3
1.2k
Reactive Thinking with Signals and the new Resource API
manfredsteyer
PRO
0
120
CloudflareのSandbox SDKを試してみた
syumai
0
180
Level up your Gemini CLI - D&D Style!
palladius
1
130
Featured
See All Featured
GitHub's CSS Performance
jonrohan
1032
470k
Git: the NoSQL Database
bkeepers
PRO
432
66k
Agile that works and the tools we love
rasmusluckow
331
21k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
659
61k
Speed Design
sergeychernyshev
33
1.3k
Scaling GitHub
holman
464
140k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
253
22k
Rebuilding a faster, lazier Slack
samanthasiow
84
9.3k
The Cost Of JavaScript in 2023
addyosmani
55
9.3k
Testing 201, or: Great Expectations
jmmastey
46
7.8k
A Modern Web Designer's Workflow
chriscoyier
697
190k
Imperfection Machines: The Place of Print at Facebook
scottboms
269
13k
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
おわり