【技術メモ】ローカルのソースをGitHubの新規リポジトリにあげる
ローカルのソースをGitHubの新規リポジトリにあげる
概要
という時の手順の備忘録
手順
事前準備
### 対象のディレクトリに移動 $ cd <対象のディレクトリ> ### とりあえずGitの管理対象にする $ git init ### ここでリモートの設定をする $ git remote add origin git@github.com:<アカウント>/<リポジトリ名>.git $ git config user.name "<アカウント>" $ git config user.email "<メアド>" ### 先にリモートのブランチを持ってくる $ git fetch $ git pull origin master ### そのまま修正してあげてもいいし、ここではdevelopを切ってプルリクの形にする $ git checkout -b develop $ git add . $ git commit -m "初回commit" $ git push -u origin develop ### プルリクをマージしておしまい。
参考リンク
ほぼこちらのサイトさんのコピーです
【技術メモ】Docker立ててローカルエディタでpython書く
概要
- Pythonの環境構築でローカルPCを汚したくない
- Dockerでサクッと環境を作りたい
- エディターは自分のを使いたい
手順
- Dockerfile作成
- buildして利用する
詳細
Dockerfile作成
適当なパスにDockerfileを用意
$ mkdir -p ~/workspace/docker-work/python-work $ cd ~/workspace/docker-work/python-work $ vi Dockerfile FROM python:3 RUN pip install requests==2.18.4 click==6.7
build して、利用する
上記で設定したコンテナを build して、その上で開発していく
$ docker build -t python-work . $ docker run --rm -it -v $(pwd):/usr/local/src/python-work python-work bash
参考リンク
【勉強会】NoOps Tokyo Meetup #3
20181207_NoOpsMeetupTokyo#3
AWSのマインドセット
光り輝くTBD（仮）
AWS Japan 西谷 圭介 さん
Undifferentiated Heavy Lifting
- 付加価値を産まない作業のこと
- 認証認可って必要だけどそれ自体は価値を産まないよね、とか
プロダクトを差別化するのはソフトウェア
Amazonのアプローチ
→Microservices/DevOps
組織体制
Two-pizza Teams
- 作るものに対する全てを負う
- ロードマップ／開発／運用／カスタマーサポート
- 独立性高く、個別に、全部やる
- QAもTwo-pizza Team
- オンコールもTwo-pizza Team
Opsは何をするのか
- Opsというポジションは存在しない
- SREもいない
- 各チームに各役割に集中するメンバーを置く
チームの水準を高く維持するために
特にテストを重視している
テストで大事なこと
- Automate Everything
- テストをしやすいようにアーキをデザインする
運用で大事なこと
- Automate Everything
- Two-pizza Teamsは人が少ないので自動化大事
まとめ
運用ゼロは幻想、NoOpsは難しくてもLessOps
テスト自動化／自動回復
Serverlessの自動化と自動回復のためのアーキテクチャ
Microsoft 牛尾剛 さん
www.slideshare.net
今日のキーワード
- サーバレス
- 自動化
- 自動回復
Markdown Translator
テストピラミッド
- E2E/ITは、SmokeTest、HappyPath、いくつかの異常系、ぐらいにしておく
- UTが80%くらい
テストがないコードは存在しないと同じ
よいユニットテストとは
- リグレッションエラーを検出できる
- False Positive（モックが本来落ちないといけないところで落ちない、とか）の割合が少ない
- 素早いフィードバック
- メンテナンスコストが低い
- シンプル
Heaganal Architecture
- アリスターコバーンが提唱
- Domain 素のクラス
- ApplicationLayer 他との会話
- その周りにいろんなサービス
モックをどこでやるか
- できるだけDomainから離れた、境界をモックにする
- なるべく自分の書いたコードをテストするようにする
- ApplicationLayerにロジックを書かず、Domainにロジックを書く
- Contorollerにロジックを書かないイメージ
- Domainはモックもなくテスト可能だから
- ネットワークコールとかどうしようもないところだけモックにする
DIとWrapper
- モックしたいクラスには絶対Interfaceをつける
- Interface単位でモックにできるから
- ライブラリでInterfaceがない時は、Wrapperで包む
テスト可能な設計のためのTips
- Domain Object
- コラボレータとの接点をMockする
- Bindingsを使う
- 単一責務の法則 一つのクラスやメソッドの役割は一つにする
- インターフェースの導入、だめならWrapper
- リポジトリパターンを使う
自動回復のためのアーキテクチャ
Durability Functions
回復させたい単位をなるべく小さく作ってリトライさせる
自動回復のためのポイント
- 単一責務の法則（Single Responsibility Principal）
- 冪等性
- リトライしたい単位で小さく関数化する
【技術メモ】Elasticsearch6にFilebeatでapacheのログ入れてkibanaで見る
Elasticsearch6を使って見る
概要
久しぶりにElasticsearch6を使って見る（2.6ぶり）
環境
- Mac OS X High Sierra 10.13.6
- Elasticsearch 6.5.1
- Kibana 6.5.0 ※間違えたけど動いた
- Filebeat 6.5.0 ※kibana間違えたのでついでに
- apache 2.4
前提
手順
Elasticsearch
$ cd <任意のディレクトリ> $ wget https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-6.5.1.tar.gz $ tar -xzf elasticsearch-6.5.1.tar.gz $ cd elasticsearch-6.5.1 ### kuromojiプラグインのインストール $ bin/elasticsearch-plugin install analysis-kuromoji ### apacheログ用のプラグインをインストール $ bin/elasticsearch-plugin install ingest-geoip $ bin/elasticsearch-plugin install ingest-user-agent ### 起動 $ bin/elasticsearch
http://localhost:9200 でアクセスして、JSONが出ればOK
Kibana
$ cd <任意のディレクトリ> $ wget https://artifacts.elastic.co/downloads/kibana/kibana-6.5.0-darwin-x86_64.tar.gz $ tar -xzf kibana-6.5.0-darwin-x86_64.tar.gz $ cd kibana-6.5.0-darwin-x86_64 ### 起動 $ bin/kibana
http://localhost:5601/ が表示されればOK
Filebeat
kibanaの画面から、チュートリアルを開けば、以下の手順は閲覧可能。
http://localhost:5601/app/kibana#/home/tutorial/apacheLogs?_g=()
$ cd <任意のディレクトリ> $ curl -L -O https://artifacts.elastic.co/downloads/beats/filebeat/filebeat-6.5.0-darwin-x86_64.tar.gz $ tar xzvf filebeat-6.5.0-darwin-x86_64.tar.gz $ cd filebeat-6.5.0-darwin-x86_64/ ### 設定ファイルを編集 (とりあえずsetup.kibanaのhostのコメントだけ外せばなんとかなる) $ vi filebeat.yml ### filebeatのapache2モジュールを有効化 ./filebeat modules enable apache2 ### apacheのログファイルの場所を指定（var.paths: ["/var/log/apache2/access_log**"]） $ vi modules.d/apache2.yml ### kibanaダッシュボードのセットアップ（終わってれば実行不要） ./filebeat setup ### filebeat起動 ./filebeat -e
FilebeatでApacheアクセスログの取り込み(レスポンスタイムフィールド追加)
画面サンプル
【読書メモ】テストから見えてくるグーグルのソフトウェア開発
【読書メモ】テストから見えてくるグーグルのソフトウェア開発
この本のまとめ
品質管理はデベロッパーの仕事
- 品質は、設計段階から作り込むもの
- テストは品質そのものではない
- 品質は最初から組み込まれていなければならないもので、あとから付け足されるものではない
- 品質管理はデベロッパーの仕事だ
Googleのしくみ
- エンジニアはSWE/SET/TEの3チームに分かれている
- カナリア、開発、テスト、ベータ、リリースのステージを通過することで品質担保する
- S/M/Lの3種類のテストを実施する
- S：完全なフェイク環境でコードの1単位をテストする
- M：フェイク環境または実環境で複数の相互作用するコード単位をテストする
- L：フェイクを使わず、実際の本番環境で、任意の個数のコード単位の塊に対して、実際のユーザが使うシナリオをテストする
品質の作り込み
- 設計ドキュメントのレビュー
- 記述に不完全な部分がないか
- 特殊な知識を必要とする部分がないか
- ずさん・雑な記載がないか
- 与えられたリソースで実現できるか
- 設計が複雑すぎないか、単純化できるか
- 設計が単純すぎないか
- 製品が使うプロトコロルが明確か
- どのようにテストできるか
- 設計を工夫してテストが楽にならないか
- コーディング
- 既存のライブラリを再利用すること
- 読みやすいこと
- 将来読んだり書き換えたりしやすいこと
- 複雑さや巧妙さよりも、再利用できることをはるかに高く評価する
- よりよい方法を思いついたらすべてのライブラリをリファクタすること
- コードレビューを真剣に行い、「読みやすさ」を他人にレビューしてもらうこと
- コードレビュー
- Googleは、コードレビューを開発の中心に置いている。
- コードを書くことよりも、レビューすることの方がずっと大切なこととして取り扱われる
E2Eの自動化にこだわりすぎると、テストは特定の設計に縛り付けられ、役に立たないものになりがち
製品の品質を向上させるために使うはずだった時間を、ずさんなE2Eテストスイートのメンテに使う羽目になる
テスト計画
- 理想的なテスト計画を実現できたものはGoogleにもほとんど存在しない
- 現実的には、ACC分析を行う
- 短時間で、書き換えやすく、テスト対象が書いてあって、進捗の度合いがわかりやすい
やっているのが「テスト」だから
品質はコードを書く人の責任
Googleのエンジニアたちは、機能の数よりも品質をとる
品質≠テスト
テストをすることが品質を担保すること、ではない デベロッパーは、プロダクトのオーナーとして品質に対して責任を負う
設計段階から品質が組み込まれていなければ、製品は決してまともなものにならない
コードレビューでは、テストコードも必ずレビューする
コードレビューでかならず「テストはどこか？」と質問する
組織
テスト自動化は、実際にはそれだけで1つのソフトウェア開発の仕事 テストコードが役立つのは、開発を加速する形で実行できる場合だけ 開発がスローダウンするのでは意味がない テスト開発は、開発の一部であって、開発から切り離してはいけない 機能コードは孤立して存在し得ない、テストコードも同様
TE
開発が中止される可能性が十分にある場合や、ユーザの関心をまだ惹きつけられていない場合、 機能セットの敵がまだ明確でない場合は、テストは主としてコードを書いている人が行うべきもの 製品が出荷されることが確実でも、機能がまだ流動的だったり、開発の初期段階では、TEがすべきテストはほとんどない
TEが判断すべきこと
- ソフトウェアの弱点はどこにあるか
- セキュリティ、パフォーマンス、信頼性、ユーザビリティ、その他懸念されることは何か
- 主要なユーザシナリオが想定通りに動作するか
- 他の製品と相互運用するか
- 問題が起きた時の診断の品質は十分なものか
ACC分析
ACC=アトリビュートコンポーネントケーパビリティ
Googleテストチームのベストプラクティスをまとめ、様々な製品分野の同僚たちが開拓したプロセス
ACCの指導原則
- 文章を書き連ねず、箇条書きにする
- 売り込まない
- 飾らない
- 行動につながらないことを含めない
- 流れを作る
- プラン立案者の思考を導く
A：アトリビュート＝属性
- 製品が、ユーザや会社にとって重要なのかはなぜか
- 製品と特徴として、競合製品から区別するための性質や特徴
- ユーザが、競合製品ではなく、この製品を選ぶ理由
Chromeであれば、速くてセキュアだ、とか。これがテストされないと意味がない
C：コンポーネント＝部品
- ソフトウェアを構成するのに必要な部品は何か
- 列挙する際の粒度が大事、10ならよいが20なら多すぎる、小さなものは省略してよい
- コンポーネントをリストアップするのに苦闘するようなら、担当する製品のことを知らなすぎる
- すぐに時間を割いて、パワーユーザレベルに達するように製品を使うべき
- リストが完全かどうかは気にしてはいけない
- ACCプロセス全体は、素早く仕事を片付けること、必要になったら作業を繰り返すこと、を基本方針としている
C：ケーパビリティ＝機能
- ケーパビリティは、入力に対する応答、クエリーに対する回答であり、ユーザのために実行される王佐
Chromeであれば、WebページをレンダリングしてFlashを再生する、とか
ACCのポイント
- ACCのポイントは、システムの中で最も重要でチェックが必要なケーパビリティを、重要なものから順にリストアップすること
- ケーパビリティで最も大切なのはテストできること
- 個々のケーパビリティが正しく実装されていて、ユーザが役に立つと感じられるようなエクスペリエンスになっているかどうかを判定するためにテストケースを書く
- ケーパビリティは、テストケースとは異なる、実際の値や特定のデータは含まない
【勉強会】Spring Fest 2018
20181031_SpringFest2018
springfest2018.springframework.jp
KEYNOTE
- Sébastien Deleuze さん
各技術状況
Java
- 2017年10月でJava8のシェアが75%
- Java11はLTS、次は17がLTS、3年ごと、それ以外は6ヶ月サイクル
- Spring5.0のサポートEOLは2019/03、どんどんアップデートする予定
- GraalVM：ハイパフォーマンスpolyglot VM、native executable
Kotlin
- 主にAndroid開発、だけどサーバでも使われてる
- 2日前にKotlin 1.3リリース
- Coroutines：ライトウィイトなスレッド
Spring Framework 5.1
- Java9/10に関してはベストエフォートのサポート
- 性能改善してる
Spring Boot 2.1
- 2.1が昨日リリース
- Java11サポート、Spring 5.1ベース、Tomcat9
- パフォーマンス改善（Startupの時間、ヒープ消費）
- Spring Data JDBC導入、ORMがフルでいらない場合のネイティブSQL
Roadmap
Spring Framework 5.2
- 来年リリース
- Kotlin1.3サポート
- Coroutinesサポート
- GraalVMをサポート
demo
- 1分くらいでnative executable作る
- Spring Bootの起動が7msで終わる
R2DBC
- Reactive Relational Database connectivity
- 非同期のSQLドライバ
- Minimal driver SPI
- Reactiveトランザクションをサポート via Reactor
- rowがストリームで返ってくる
RSocket
- ネットワークのReactive
- Reactive streams back pressure over the network
- RequestResponse/FireAndForget/Request-Stream/Channel（双方向ストリーム）どれもいける
- Java/JavaScript/C++/Kotlinをサポート
Spring Fu
- インキュベーター(incubator)
- 起動とメモリ消費がさらに改善
- Kofu configuration
- Jafu configuration
- ファンクショナルなコンフィギュレーション
まとめ
SpringとPCFで作るクラウドネイティブ
決済システムの内製化への旅 - SpringとPCFで作るクラウドネイティブなシステム開発
- Pivotal 槙 俊明 さん
- ソフトバンク・ペイメント・サービス株式会社 鈴木 順也 さん
www.slideshare.net
内製化に至る道のり
2016年
開発はベンダーに丸投げ、開発できる社員がゼロの状態でJOIN
- 課題：運用の手作業が多く、ミスも多い
2017年
課題：サービス状況をすばやく把握できてなかった
- ElasticStackを導入
課題：古いアーキテクチャのため、開発が高コスト、監視が困難
- SpringBoot/SpringCloudを導入
- Jenkins/Nexus/sonarqubeを導入、CIを当たり前に
2018年
システム本体の内製化をスタート、PivotalCloudFoundry導入
- スピード感のある開発・リリース
- 継続的な改善サイクル
- 監視を強化して障害に強いシステム
PivotalCloudFoundryを選んだ理由
Why PaaS？（Kubernatesじゃなく）
- 「I'd like less responsibility」
- 開発者に余計なことをさせたくない、PaaSはできることが良い意味で限られている
全体アーキテクチャ
- DevはPrdと同環境で用意する
- MW系の管理は、Cloud Foundry BOSHで管理（ChefやAnsibleでなく）
- APIGatewayでルーティング（Spring Cloud GatewayのProxyExchangeで実装）
- システム間連携にはHystrixを入れてCircuit Brakerを実装
- 非同期連携はRabbitMQ＋Spring Cloud Stream、返せなかったらDeadLetterQueue
- アプリケーションのオートスケール、PCF App Autoscaler（PaaSではおなじみの機能）
12 Factor App
- アプリで重要なのは3,6,7,8,11
- 6,7,8はSpring Bootならほぼ満たされる
- 3、環境依存の設定は環境変数に格納
- 11、標準出力からLogStashへ
絶対ロストしたくないログは、トランザクションデータと割り切ってRDBへ
CI/CD
- PivotalのConcource
- ビルドパイプラインが視覚的にわかりやすい
- 設定はYAML
CI
GitHubにPush -> JUnit/SonarQube -> Nexusにアップロード -> テストサーバにデプロイ
CD
ConcourceCIを手動クリック -> masterブランチにマージ -> UT -> バージョンタグ -> ビルド -> Nexusアップロード -> 本番環境へデプロイ
というのは一例、実際には人によるリリース判断が入る
リグレッションテスト
Javaのバージョンアップ
- 複数のバージョンを同時にテスト可能なCI環境を用意
- 簡単にデプロイ可能なDev・Staging/Prod環境を用意
- 塩漬けするのではなく、アップデートし続けられる環境を準備
Observability
Metrics/Tracing/Logging
- Metrics：Grafana/Prometheus/Micrometer
- Logging：Elasticstak
- Tracing：ZIPKIN
アプリ側には依存を追加するだけ
エンタープライズアジャイル
エンタープライズアジャイルと Spring/Wagby の親和性
- 株式会社ジャスミンソフト 贄 良則 さん
エンタープライズアジャイルとは
SoR
社内利用、経費削減のためのIT
SoE
社外利用、売上アップのためのIT
DX：デジタルトランスフォーメーション
全ての企業がSoEへ踏み出さなければ、Amazonに蹂躙されますよ、という恐怖感
アジャイルの思想
「利用者と開発者が密にコミュニケーションをとって、必要なものを作る」
不要かもしれないものでも、計画してしまったら作るしかない、というエンタープライズへのアンチテーゼ
大規模案件でも使えるのか
- 大手SIerが実績として掲げる「アジャイル開発」の事例は、ほぼ例外なく小規模案件
- アジャイル開発には、丸投げ不可・責任の押し付け合い不可、というドグマが存在
- ユーザに、コードを書く以外のことはなんでもやる、という気概が求められる
- SoEでアジャイルがうまくいくのは、ユーザにその気概があるから
なんのためのエンタープライズアジャイルか
- 開発費と保守費の削減
- 開発スピードアップ
- ユーザによるシステムイニシアチブの確保
SoRを支える情シスの心構え
改めて、エンタープライズアジャイルとは
- SoRとSoEの垣根をなくすムーブメントにつながる
- SoRはなくならない、が、抜本的な改革が必要
楽天トラベルでのSpring
Rakuten Travel and Spring
- 楽天トラベル Kalburgi Gajraj さん
Spring Initializr
- 楽天では、InitializrのWebをラップして使ってる
Spring Cloud Configurations
（GitHubに本番の設定ファイルもいれるんだろうか？）
Actuators
Actuatorのエンドポイント（例）
- /health：ヘルスチェック
- /info：Mavenの情報？
- /env：Spring Configurationの環境情報
- /loggers：ログの設定、ここで変更もできる？
Spring Boot Admin でActuatorのAPI呼ばなくても可視化してくれる
Swagger
- 可視化に使ってる
- APIの簡易テストドライバとしても
Observability
Observability with Spring-Based Distributed Systems
- 楽天トラベル Thomas Ludwig さん
What is observability
- データとコンテキストとして、何か気づきを得られる
- 部分的な故障
- 予想できないことを予想する
- 知らなかったことを知れる Beyond traditional monitoring
障害は必ず起こる、どれだけ早く検知・理解・修復できるかが重要
Observabilityの3つの側面
- Logging
- metrics
- tracing
Logging
Spring Cloud Sleuth でリクエストにtraceIDを埋める
- アプリは依存性を追加するだけ
- 設定はSpring Cloud Configで設定は共通設定
Metrics
Micrometer で、Metrics backendにデータを送る
- backendはいろいろ対応してる（Prometheusとか、Datadogとか）
- micrometer-registry-prometheusをdependencyに追加するだけ
- 設定はSpring Cloud Configで設定は共通設定
Alertに関して。
Double Alerts にしない
- サービスが増えると、1つの障害が何箇所でもアラートが出る
- ユーザにエラーが返ってないなら、アラート不要
Tracing
Zipkinで、プロセスを跨いだ分散トレーシング
- spring-cloud-zipkin-starterを依存性を入れるだけ
- 設定はSpring Cloud Configで設定は共通設定
- 取得される値はサンプリング、サンプリングの％はConfigで設定
- 非同期でも、トレースできる
テストにも使える
まとめ
- Observabilityを意識しよう
- ツール組み合わせよう
LINEでのSpring
500+のサーバで動くLINE Ads PlatformをささえるSpring
- LINE株式会社 渡邉 直樹 さん
www.slideshare.net
（Springに限らず、LINEの広告管理システムで使っている技術の説明。）
Java
maxGCPauseMillis
- maxGCPauseMillis,default 200ms
- 20msに設定したら悪化した
- あまり積極的な設定にするとむしろ遅くなる（と公式にも記載あり）
- 結局、ヒープを増やした
- Java11のZGCに期待
Java以外
Golang
Kafka
- 高速、安定
- 一度入れてしまえば、後から非同期でコンシュームしてデータが見れる
- Consumerごとにどこまでデータを読んだかを管理している、データを消さない、ってところがいい
- 高負荷で受けられないとか、送った送ってない問題
- 各サービスは、Kafkaに書き込むまでを責務とすることで、責務分解が明確になる
- QueueやJob schedulerとしても使える
️⃣### Kafka難しくないの？
- SpringBootと相性がいい
- コードをあまり書かなくていい
- spring-kafkaもいいけどSpringのバージョンに引きずられる
- 公式のkafka_clientが十分おすすめ
- Kafka streamsはシンプルに使えてイイ
LINEのアーキテクチャ選定の基準
LINE Adsチームの最近の開発
- SpringBoot2
- Reactor
- Kafka
- actuator/micrometer -> Prometheus/Grafana
Reactor
- Ractive streams
- Non-blocking + Back pressure
- BackPressureはあまり使ってない、Kafkaがあるから
- WebFlux, Lettuce5
- Flux, Mono
Lettuce5
- Reactive API
- Redisとつながる
- 戻り値がMono/Flux
- すごくスッキリ
Spring Data REST / Spring Cloud Contract
Spring Data REST と Spring Cloud Contract
- 株式会社タグバンガーズ 小川 岳史 さん／山﨑 大 さん
www.slideshare.net
Spring Data REST
HATEOAS
SpringData RESTのレスポンスは、DATA部とLINK部で分かれている
- LINK部はHATEOASというスタイルに準拠している
- HATEOAS:Hypermedia As The Engine Of Application State
- 次にできるアクションのリンクを返せる
- フロントエンド側でURLを組み立てなくていい
例えば、statusがPENDINGかPAIDだったらキャンセルできる、みたいな仕様の時
バックエンドで実装できた方がイイ
SpringDataRESTの実例
- 管理機能
- 現実的に、エンドユーザ機能は単純CRUDではすまないケースが多い
- 管理機能のみに導入した
- 全文検索
- HibernateSearchというライブラリ使うとElasticSearch繋げる（！！）
- マルチテナント
- SpringSecurityと組み合わせて、WHERE句にテナントを埋めるようにHibenateをカスタマイズ
Spring Cloud Contract
解決したい課題
- 破壊的な変更をデプロイする前に、ビルド段階で検出したい
- 自動テストがダイジ
解決案
- モックに置き換える
- モックは本当に正しいの？
- モックは誰がメンテするの？
そこで、Spring Cloud Contarct
- ただ、ConsumerもJavaじゃないと使えない
- Angularでは使えなかった
そこで、Pact
- SpringBoot2からPactがサポートされた
Consumer Driven Contract
APIを使う側がどう使うつもりか、を定義する
ConsumerのContractファイルでテストできる
破壊的なAPIの変更があれば、ここで気づける
Spring Cloud Contract
- Contractファイルからビルド時にテストを自動生成できる
- モックも自動生成（WireMockの定義ファイル）できる
Pact
さまざまな言語をサポート
Micrometer/Prometheus
Micrometer/Prometheusによる大規模システムモニタリング 〜ヤフーインターネット広告システムでの導入事例〜
- ヤフー株式会社 池田誠さん
Prometheus
- 時系列DB＋モニタリングシステム
- pull方式（ZABBIXはpush方式）
- KeyValueのテキストデータでデータ連携
- PromQLという独自クエリで検索／可視化が可能、Grafanaでダッシュボード
- 注意点
- 時系列DBが冗長化できない
- 同一構成のPrometheusを用意するか、InfluxDBなど別の時系列DBを使う（有償）
Micrometer
- メトリクス収集のライブラリ
- SpringBootならDependency追加＆設定のみでOK
- 様々なモニタリングシステムと連携可能、CloudWatchもOK
- 設定
- pull型なら、Actuatorでエンドポイント公開
- push型の場合は送信先を設定
- CloudWatchの場合は認証情報なども必要
取れるもの
採用理由
要件
- IaaS/PaaS/CaaSのどのPFにも導入可能なこと
- 監視対象アプリへの導入が容易、SpringBootならコード修正不要なこと
- アラートが出せること
- グラフ可視化できること
- メトリクスがカスタマイズ可能なこと
Micrometer
-
というか、他に競合製品がない
Prometheus
- 時系列DBなのでグラフ描画に最適
- pull方式のためエージェントレス（PaaSには課題あり）
- 1万ノード監視の実績
- SRE本でも紹介
- コミュニティーが活発で将来性マル
数千台あるとエージェントレスでもきつい
数千インスタンスをPrometheusに設定する運用コストが高い
- そこで、サービスディスカバリを導入
- Netflix-Eureka（eureka-client-starter）
- Eureka連携ツールは自作
Prometheusのサーバスペック
特別大きくない
課題
PaaS
PaaSの場合、Prometheusがpullが綺麗にとれない
- 原因
- PaaSのルータがバランシングしてしまい、インスタンスが狙い撃ちできない
- 対策
- PushGatewayというサービスを挟んで一時手当（対応模索中）
JAX-RS
Micrometer導入後数時間でGC連発
- 条件
- 原因
- Pathパラメータごとにメトリクス収集され、データが爆増し、メモリ逼迫
- 対策
SpringMVCなら何もしなくてもPathパターンごとに収集可能
カスタムメトリクスを使う場合、メトリクス数の爆増に注意。メモリ逼迫もだし、検索性能も劣化する
Prometheusの性能問題
- 複雑なクエリを並列実行するとOOMキラーが発動してPrometheusが死ぬ
- 複雑＝1時系列あたり数万メトリクスで、数週間分とる、とか
- 対策
- PrometheusのRecordingRuleで回避可能かも（検証中）
まとめ
- 良かった点
- 導入コスト超低い
- カスタマイズ性抜群、見たい人が見たいものを勝手に見てくれる
- 悪かった点
- PromQLの習得に学習コストがかかる
- Webに情報が少ない
- Yahooレベルの大規模システムでも利用可能なのでみなさんもぜひ
