Forem: mizuki04

[Tips] Rails6起動時のError対応

mizuki04 — Wed, 03 Feb 2021 17:13:02 +0000

Errorの対処

localへrailsを入れただけでは、以下のエラーが出てしまった為、起動までのステップを備忘として載せる。

cannot load such file -- nokogiri/nokogiri (LoadError)

上記の対応としては、arm64版のモジュールが不必要に入っていることによって、エラーが起きていた為。一旦それを解消する。

①一旦nokogiriをアンインストール。

②Gemfileにgem 'nokogiri', '~> 最新版'を記載

https://github.com/sparklemotion/nokogiri/releases

③nokogiri (1.11.1-arm64-darwin)をGemfile.lockから削除

④gem install nokogiri

上記の問題はこれで解消したが、それだけではwebpackerのエラーが発生するため。

 Webpacker configuration file not found

⑤rails webpacker:install

上記を行うことによって解消され、ひとまず起動。

[BookLog] グレートカンパニー

mizuki04 — Tue, 02 Feb 2021 18:58:17 +0000

概要

ソフトエッジ
・信頼
・知性
・チーム
・テイスト
・ストーリー
ハードエッジ
・スピード
・コスト
・サプライチェーン
・流通
・資本効率
戦略的基盤
・市場
・顧客
・競合他社
・競争優位性
・変革者

本書の中心的な主題はソフトエッジについて語られている。そして最も重要な軸として捉えられている。(Forbsの観察結果という根拠に基づいて)

ソフトエッジで優位にたつと、ブランド認知が高まり、利益率が上がり、得意先が増えて、熱心な従業員が増える。コモディティ化している市場から頭ひとつ抜けるキッカケ

ソフトエッジが優れている会社は、戦略上大きなミスを犯しても、生き延びられる場合が少なくない、忠実さと情熱と献身が、強いソフトエッジの配当

ハードエッジがしっかりしていても、束の間の利益しかあげられない、ハードエッジは技術、softwareなどの知的資産が安くなるにつれて簡単に真似されてしまう。

memo

・新しいことを学んだり、初めてぶつかった問題を解決する能力⇨流動性知性
・学んだ結果を応用する能力⇨結晶性知性

上記の能力を「何かしらの事柄をやり抜く」という姿勢が研鑽していく為、結果的には困難な状況に対して粘り強く取り組めるかということが最重要（スマートである）とされている。

・データと人間的真実の間にある、見つけるのが難しいポイント（最適打球点）がテイスト
※必ずしも新たに作られた物である必要はない、真似でもいい

[Booklog] ベタープログラマ(O'Reilly)

mizuki04 — Mon, 01 Feb 2021 08:52:10 +0000

[備忘のためのメモ]

ch3_少ないコードを書く

※コメントを書くときに意識すること

•コード自身は、何をどのようにしてを説明しているため、コメントでは「なぜ」を説明すること、しかし何故を説明する際にコードがかつて行っていたことを記載しないようにすること。

ch10_バグ狩り

※問題解決を速やかに行う為に

•素早く、バグを特定する為にはバイナリチョップを行う、具体的にはコードのパスをひとつづつ実行するのではなく、事象の連鎖のはじめと終わりから始める。それから問題空間を二分して、中間点が良い状態か悪い状態かを調べる。それを繰り返して二分探索的に問題を特定する。（よくない打ち手としては1ステップずつ実行すること）

ch13_二つのシステムの物語

※優れた構成を産むために

• コードを書き始める前に、意図して事前の設計を行うこと。多くのプロジェクトは、実際に開発する前にこの点で失敗し、そこには対立する緊張がある。設計が足りなさすぎず、その上過剰設計でないこと。

• 開発を進めながら、設計を明瞭に維持し続けること。

• ソフトウェアの全体設計の責任が与えられて、責任を持つチームであること。

• 設計を変更することを恐れないこと。永久に変わらないものは無し。

• チームにふさわしい人々を入れること。そこには設計者、プログラマ、マネージャが含まれる。開発チームを適切な大きさにすること。彼らが健全な関係になるようにする。彼らの関係が必然的にコードの構造へ反映される。

• 設計上の決定を、決定するためのすべての情報を分かっている適切な時期に行う。まだ行えない設計に関する決定を遅らせること。

ch24_学びを愛して生きる

※スキル獲得のドレイファスモデルを読んで要点の抽出

• 初級者
経験が学習を導く、規則を破って独自のやり方を試すが、うまくいかなくなると行き詰まってしまう。関係のない詳細を省くことができない。

• 中級者
全体像を持つことで、未知な問題に対処したり、問題に対する方法論的な筋道を計画できる。新たな規則の限界も把握し始める。

• 上級者
全体像の深い理解、自らの経験からだけでなく他人の経験から学び、理解して吸収できる。問題に対するデザインパターンを持っている。

• 専門家
専門家は理解を極めた結果、直感を持っているので、規則を必要とせずに答えが自然にわかる。

ch31_一生懸命でなく、賢く

※新たな作業が依頼されたら

• 今実際に必要とされているのが、なんであるかを調べること。初期の段階でTooMuchにやることを積み上げるのはやめること。

パレートの法則
https://blog.kairosmarketing.net/marketing-strategy/how-to-leverage-pareto-law-into-marketing-activities/

[DevSecOPS] #7 CI/CD自動化パイプラインの実現①構想編

mizuki04 — Thu, 10 Sep 2020 20:05:31 +0000

CI/CD自動化パイプラインの実現①構想編

1.はじめに

前回の記事によって、アプリケーションを包括的にウォッチする環境が概ね整ったことが分かります。そこから、メモリリークやDBのスペック調整を一通り行い、クラウドサービス上で動く現行環境のチューニングや細かいセキュリティ上の問題を一度解消することができる手がかりが得られると思います。

・前回の記事（見える化を行ったら(APサーバ編)）
https://dev.to/mizuki04/devsecops-1hf

しかし、監視基盤から得られる諸問題は各サービスの状況に依存したスペシフィックな問題である為、打ち手について今回は割愛します。

今回取り上げるのは、一度上記のように環境をブラッシュアップした時にさらにもう一つ抜本的な改革を進める為にはという問いに対する一つの実行例を述べます。

一般的にサービスをリリースして安定的にユーザを獲得できている場合、最も避けたいのはダウンタイムだと思います。そこで気になるポイントとして、本番環境のデプロイに時間がかかっている、だったり手動によるデプロイの為ヒューマンエラーに繋がる等の事象が見受けられます。

できるならmasterブランチにマージを行ったら、そのあとはコーヒー☕️でも飲みながら一服をしたいと思うのは自然な発想です。

それを実現するのが、CI/CD自動化パイプラインの実現です。

※CI/CDとは「Continuous Integration／Continuous Delivery」の略で、
日本語では継続的インティグレーション／継続的デリバリーといいます。
CI/CDは1つの技術を指すものでなく、ソフトウェアの変更を常にテストして
自動で本番環境にリリース可能な状態にしておく、ソフトウェア開発の手法を意味します。
CI/CDを取り入れると、バグを素早く発見したり、変更を自動でリリースしたりできるようになります。

パイプラインのポテンシャルを引き出して、ダウンタイムを最小にする為には、アプリケーションをDockerlizeし、コンテナベースの運用にすることがほぼ不可欠であるのでそちらも踏まえて今後記載していきます。

2.ソース管理の環境と選定サービス

上記を実現するにあたり、ソースを管理しているサービスによって実現の方法は異なります。概ね、Github/Gitlabどちらかになるかと思いますが、今回はGitlabのユースケースを用いてこのプロジェクトの解説を行います。

Githubの場合はGithubActionsやCircleCIなどが一般的なように思え、Gitlabの場合は、CICDのサードパーティサービスに加え、Gitlab標準のGitlabCIという機能があります。

また、AWS環境ならばCodepipelineなどのマネージドサービスが存在します。

予算や規模感に応じて取れる選択肢は変わりますが、コスト・時間的なパフォーマンス・周辺機能の充実で選ぶと間違いないかと思います。従量課金制のサービスが多い中、今回のユースケースでは、コストが無料であるGitlabCIを選択致しました。

3.クラウドサービスの環境とコンテナオーケストレーションツール

AWS/GCP/Azureそれぞれの環境に合わせて、CI/CD周りの自動化を行うならばコンテナオーケストレーションツールの利用もほぼ必須だと言えるかと思います。

今回は、AWS環境のEC2インスタンスベースで運用を行なっていたサービスを移行する為
AWSフルマネージド型のコンテナオーケストレーションサービスであるECSを選定致しました。

https://aws.amazon.com/jp/ecs/

他にはAWSでも、フルマネージド型の Kubernetes サービスであるEKSも登場しています。ECSを選定した理由としては、現在行っている運用作業を減らすとともに、可視化や拡張性を担保できるなど以下のメリットが考えられます。

可用性
- 障害時も予約したタスク数で自動復旧できる
性能・拡張性
- スケーラビリティ
- ECSではインスタンス数/タスク数を増やすだけ
- 台数調整・インスタンスタイプなどはCloudFormationから
運用 / 保守性
- コンテナ化にあたり、ビルドやデプロイと言った作業を自動化できる
- 監視の追加(XX_exporterなど)は公式イメージを追加するだけ
- コンテナ追加が容易な為ツール導入でテストカバレッジ等を可視化できる
セキュリティ
- AWS側に保持している、コンテナをECRと組み合わせて診断できる
移行性
- 別のコンテナオーケストレーションとは異なり、仕組みがシンプルで、馴染みのあるEC2をそのまま利用することができる等です。（VPC,ELB,EC2 etc...）。

パイプライン＋コンテナオーケストレーションツールによって、デプロイの自動化・GUIベースでのアプリケーションの管理が可能となります。

今回目標としていたのは、0.5~1時間程度のデプロイに手動で掛かっていた時間を完全に自動化することです。

次回からは具体的なhowの話を行いたいと思います。

[Tips] 中銀カプセルタワービル=Docker説

mizuki04 — Sun, 16 Aug 2020 18:22:44 +0000

今回初めてのTips投稿ですが、何かの理解の一助になればなと思ったものについて、備忘も込めて投稿していきます。今回はDockerの概念を簡単に説明するには、、、と考えた時にこんなやり方もあるのではと模索した結果です。名付けて、

「中銀カプセルタワービル=Docker説」

https://speakerdeck.com/mizuki0414/zhong-yin-kahuserutawa-equals-dockershuo

[DevSecOPS] #6 見える化を行ったら(DBサーバ編)

mizuki04 — Sun, 16 Aug 2020 17:55:50 +0000

1.はじめに

運用を行う上でDBの状態の把握は一般的なサーバの監視項目に加えて、優先度の高い物であると認識しています。DB自体について知りたいことはAPの特性によって変わるかと思われますが、今回も一般的な項目について整理していきたいと思います。また今回はNoSQLベースのDBであるMongoを想定して記載致します。

2.DBサーバへの監視項目

基本的な監視項目についてはダッシュボードを参考に以下を整理しました。
・DBコネクション数
・オペレーション数（CRUD）の増減率
・DBのメモリアロケーションの増減率
・(In-Out)Byte数の増減率
・Lockの実行数
・Pagefaultの合計数

3.Metrics

では実際のクエリを記載していきます。演算子に関しては一旦無視していただき、Mongoから取得したMongoDBexporterのメトリクスについてをメインで考えています。

DBコネクション数

irate(mongodb_connections[1m])

オペレーション数（CRUD）の増減率

irate(mongodb_mongod_op_counters_total[1m])

DBのメモリアロケーション

irate(mongodb_memory[1m])

(In-Out)Byte数の増減率

irate(mongodb_network_bytes_total[1m])

Lockの実行数

mongodb_mongod_global_lock_current_queue

Pagefaultの合計数

mongodb_extra_info_page_faults_total[1m]

4.結び

ダッシュボードをインポートして使用するのでも十分ですが、本質的にはクエリの詳細についての理解を怠ると何を表しているのか正確に把握できない為自戒を込めて記載致しました。アラート発火の閾値に関しては、運用を行いつつチューニングすることが望ましい為今回はメトリクスの紹介となりました。

[DevSecOPS] #5 見える化を行ったら(APサーバ編)

mizuki04 — Sat, 15 Aug 2020 12:50:44 +0000

1.はじめに

モニタリング（監視）の環境を整備することによって、見える化を行ったら次はどんな情報が必要で、何を整理する必要があるか考えなければならないですね。

基本的には必要な情報はサーバ郡の役割によって異なる為、大きくAPサーバとDBサーバで分けて検討します。

求められるビジネスロジックによって必要なメトリクスは異なるが、今回はオーソドックスであると思われるものについてまとめていきたいと思います。

また今回想定している環境はprometheusの為、他の基盤を用いている方はメトリクスを自分の基盤と読み替えていただけると幸いです。

前提として、各メトリクスを取得する手段は、goによって作成されている**.exporterを使用しpull型の取得であるとしています。

2.APサーバへの基本的な監視項目

項目	閾値	scrape_interval	evaluation_interval	alert_interval	型
死活監視	回	10sec	10sec	1min	bool
CPU使用率	%	1min	1min	5min	avg
メモリ使用率	%	1min	1min	5min	avg
ストレージ空き容量	%	1min	1min	5min	max
ロードアベレージ	数	10sec	10sec	1min	avg
diskIO	%	10sec	10sec	1min	max
diskbusy	%	10sec	10sec	1min	max

必要最低限を満たす大勢として、検討したメトリクスとしては上記のようなものでした。

上記の値を取得してアラートを発火するには、Grafana,もしくPrometheus側のアラートマネージャにクエリを記載しなければならないのですが、Prometheusへ蓄積した様々なメトリクスの参照は、PromQLという独自のクエリ言語を用いて行います。

また、GrafanaのTemplating機能を使うと、クエリに対して変数が適用できますが、IaC的な運用を目指すならばアラートマネージャ側でクエリを保持して管理する方が良いかと思われます。

3.Dataの取得方法

さて、ここで上記の項目値の取得方法の例を記載します。その前に必要な演算子は以下のようなものがあります。

max,min
任意の範囲内でのデータの最大、最小
avg
avg演算子は、レコードごとに格納されたスカラー値の平均値を返します。レコードのvalueが配列（Range Vector）の場合は適用できません。
rate()とirate()
rate()とirate()関数はどちらも、ある時間範囲で取得したデータが、1秒あたり平均どれだけ増加しているかを計算します。
withoutとby
without句は上述の通り、指定したラベルを無視して集計関数を適用します。実際にwithout(cpu)を実行した場合の生データは以下のように、cpuラベルが欠落した状態になります。{instance="docker104:9100",job="node",mode="user"} 0.0005000000000002558
by句は逆に、指定したラベルに絞って、つまり他のラベルを無視して集計関数を適用します。by(mode)を実行すると、mode以外のすべてのラベルが欠落した状態になります。

4.実際のクエリの例

CPU使用率

sum by (instance)(avg(irate(node_cpu_seconds_total{instance=~"$node",mode=~"user"}[5m])) without(cpu) * 100)

指定インスタンス($node)の、単位時間($interval)内での1秒ごとのCPU使用率の平均を表示します。

# HELP node_cpu Seconds the cpus spent in each mode.
# TYPE node_cpu counter
node_cpu{cpu="cpu0",instance="docker104:9100",job="node",mode="iowait"} 1.57
node_cpu{cpu="cpu0",instance="docker104:9100",job="node",mode="system"} 42.51
node_cpu{cpu="cpu0",instance="docker104:9100",job="node",mode="user"}   74.37
node_cpu{cpu="cpu1",instance="docker104:9100",job="node",mode="iowait"} 5.13
node_cpu{cpu="cpu1",instance="docker104:9100",job="node",mode="system"} 34.1
node_cpu{cpu="cpu1",instance="docker104:9100",job="node",mode="user"}   72.7

ロードアベレージ

node_load1{instance=~"13.231.98.14:9100"}

死活監視

単純な死活監視については別途Exporter(Blackboxexporter)が出ていますが、何らかの基本的な値が一定間隔でnullになった場合に発火するでも問題ないと考えています。

メモリ

process_resident_memory_bytes
process_virtual_memory_bytes
( node_memory_MemFree_bytes{instance=~'$node'} - node_memory_Buffers_bytes{instance=~'$node'} + node_memory_Cached_bytes{instance=~'$node'} + node_memory_SwapCached_bytes{instance=~'$node'} + node_memory_Slab_bytes{instance=~'$node'} + node_memory_PageTables_bytes{instance=~'$node'} + node_memory_VmallocUsed_bytes{instance=~'$node'} ) /  node_memory_MemTotal_bytes{instance=~'$node'} * 100

ディスク使用量

100.0 - 100 * (node_filesystem_avail_bytes{instance=~'$node',device !~'tmpfs',device!~'by-uuid'} / node_filesystem_size_bytes{instance=~'13.231.98.14:9100',device !~'tmpfs',device!~'by-uuid'}) or 100.0 - 100 * (node_filesystem_avail{instance=~'13.231.98.14:9100',device !~'tmpfs',device!~'by-uuid'} / node_filesystem_size{instance=~'13.231.98.14:9100',device !~'tmpfs',device!~'by-uuid'})

ディスクIO

rate(node_disk_read_time_seconds_total[5s] / rate(node_disk_reads_completed_total[5s]) * 100

(rate(node_disk_read_time_seconds_total{instance=~"13.231.98.14:9100"}[5s] / rate(node_disk_reads_completed_total{instance=~"13.231.98.14:9100"}[5s]) )* 100

5.監視から得られる示唆

上記で挙げたような、項目は本当に一般的なものですが、注意深く見ると、時系列と共にデータから得られる示唆が沢山あります。

例えば、今回のケースでは社内のadminユーザが業務時間と共に複数セッションを開始しメモリの負荷が業務開始と共に上がっている、といったような示唆がありました。

そこから得られるのは、インスタンスタイプを直ぐにあげてメモリを増強する。ではなく、セッションの開く数を減らしてもらうように呼び掛けたり、admin周りの機能改修によってメモリの使用を抑えるような打ち手も考えられます。

結びとしては、監視⇨障害検知といったことだけではなく、スペックの最適化やシステムの使い方まで話が発展できる為、良い基盤の構築は業務を支える力強い味方になってくれると考えています。

[DevSecOps] #4 Prometheus + MongoDB監視導入手順

mizuki04 — Thu, 06 Aug 2020 04:39:26 +0000

Prometheus + MongoDB監視導入手順

①はじめに

当記事は前提として、Prometheusサーバがすでに構築されていることを前提とする。詳しい構築手順は別資料参照(#Prometheus+Grafana監視基盤導入手順)

②Installing the MongoDB exporter

MongoDB exporter は右に記載のGitからCloneできる Percona’s GitHub here.

goやdockerを使ってインストールを行うことができるが今回は環境の依存性を考慮してバイナリファイルを実行する形式について説明をする。

また、下記のバイナリファイルを実施するにあたりMongoDB自体にも設定を行う必要がある。

まずはインストール。

$ mkdir mongodb-exporter
$ cd mongodb-exporter
$ wget https://github.com/percona/mongodb_exporter/releases/download/v0.7.1/mongodb_exporter-0.7.1.linux-amd64.tar.gz

次に解凍をして。

$ tar xvzf mongodb_exporter-0.7.1.linux-amd64.tar.gz

おそらく右のファイルが解凍されると思う: mongodb_exporter, LICENSE, README.md, CHANGELOG.md.

サービスを実行していくにあたり、Prometheusにもモニタリング用のユーザを作成する必要があるがこちらは(#Prometheus+Grafana監視基盤導入手順)で実施済みのため割愛する。

$ sudo useradd -rs /bin/false prometheus
$ sudo mv mongodb_exporter /usr/local/bin/

③MongoDBの設定

MongoDB監視を行うにあたり、exporterがDBにアクセスできるようにモニタリングユーザ作成と、環境変数のパスを通してやる必要がある。（デフォルトポートをしようしていない場合はそれも設定する。）

MongoDB認証は–auth flagをMongoShellから立ててやる必要がある。デフォルトでは未設定なので、以下のように実行していく。まずはMongoのプロセスが生きているかを確認する。

$ ps aux | grep mongod
mongodb  13468  1.1  6.9 1490632 281728 ? Ssl  Jan05 2838:27 /usr/bin/mongod --unixSocketPrefix=/run/mongodb --config /etc/mongodb.conf

mongoコマンドでMongoインスタンスにログインする。

$ mongo --port 27017

Exiporter用に administrator accountをcluster monitor roleを付与して作成する。

use admin
db.createUser(
  {
    user: "mongodb_exporter",
    pwd: "password",
    roles: [
        { role: "clusterMonitor", db: "admin" },
        { role: "read", db: "local" }
    ]
  }
)

正しく作成されていれば、以下のメッセージが出力される。

Successfully added user: {                        
        "user" : "mongodb_exporter",              
        "roles" : [                               
                {                                 
                        "role" : "clusterMonitor",
                        "db" : "admin"            
                },                                
                {                                 
                        "role" : "read",          
                        "db" : "local"            
                }                                 
        ]                                         
}

MongoDB instanceを再起動する。

$ db.adminCommand( { shutdown: 1 } )
$ exit
$ sudo mongod --auth --port 27017 --config /etc/mongodb.conf &

次にMongoDB URI を以下のように変更する。

$ export MONGODB_URI=mongodb://mongodb_exporter:password@localhost:27017

④MongoDB exporterサービス起動設定を行う

/lib/systemd/systemへ移動し、サービスファイルを作成する。

$ cd /lib/systemd/system/
$ sudo touch mongodb_exporter.service

[Unit]
Description=MongoDB Exporter
User=prometheus

[Service]
Type=simple
Restart=always
ExecStart=/usr/local/bin/mongodb_exporter

[Install]
WantedBy=multi-user.target

上記でサービス起動をデーモン化

$ sudo systemctl daemon-reload
$ sudo systemctl start mongodb_exporter.service

これで、サーバリスタート時でも再起動が自動でかかる。

Percona’s MongoDB exporter は port 9216で動作するので、一旦動いているか確認する。以下のようにメトリックスの情報が取れていればOK

$ sudo curl http://localhost:9216/metrics
# HELP go_gc_duration_seconds A summary of the GC invocation durations.
# TYPE go_gc_duration_seconds summary
go_gc_duration_seconds{quantile="0"} 0
go_gc_duration_seconds{quantile="0.25"} 0
go_gc_duration_seconds{quantile="0.5"} 0
go_gc_duration_seconds{quantile="0.75"} 0
go_gc_duration_seconds{quantile="1"} 0
go_gc_duration_seconds_sum 0
go_gc_duration_seconds_count 0
...

⑤ メトリクス取得に関する起動オプション

Prometheusから起動を確認できたら次は起動オプションについて説明する。

先ほどはサービスファイルを作成して起動をした。だが起動時にうまく環境変数を読み込めない等の事象が散見される為、以下のように念の為環境変数指定の起動オプションを実施する。

サンプルだが以下のような、コマンド例となる。

$ ./mongodb_exporter --mongodb.uri=mongodb://user:passward@127.0.0.1:27017 &

--mongodb.uriオプションで渡せる引数はmongo環境変数の内容である。またこのときBasic認証をオンにしていると、Prometheusからexporterにアクセスする時に引数を指定してアクセスをしないとならない為、必ず$HTTP_AUTHがNullであることを確認する。

⑥ダッシュボード作成

別紙で説明した通り、データソースをインポートして、ダッシュボードのソースを指定する。

既存のダッシュボードを使いたい場合は、Jsonをさらにインポート

インポートした後に、クエリの設定をしてやればDB監視の、ダッシュボードが作成できる。

[DevSecOps] #3 Prometheus,Grafanaを使用したサーバ監視基盤の構築手順

mizuki04 — Thu, 06 Aug 2020 04:31:41 +0000

Prometheus,Grafanaを使用したサーバ監視基盤の構築手順

目次--------------------------------

0.はじめに

1.Architecture

2.Prometheus導入手順

3.Node_exporter導入手順

4.Grafana導入手順①(インストール＆初期設定)

5.Grafana導入手順②(ダッシュボード初期設定)

-----------------------------------

0.はじめに

監視運用を行う上で、クラウド環境上の既存ツールを利用しているが、グラフの描画が見にくかったり、アラート通知の設定が複雑だったり、サーバ増築時の追加設定が面倒だったりと痒いところに手が届かないポイントが幾つかあるかと思います。そんな時にオススメできるのがPrometheus(監視)+Grafana(可視化)の監視体制がオススメです。具体的には以下の点が容易に実装できることがメリットです。またPrometheusはSoundcloud(https://soundcloud.com)社がリリースしているツールであり、Soundcloudのサービスに馴染みがある方もいるのではないかと思います。

監視対象のサーバーから情報を取得 & 保管
保管済みデータに対して集計クエリを発行できる
しきい値を超えた場合のアラート (メール、Slack、がんばればTwilioで電話)
柔軟なアラート設定 (同じエラーはまとめて通知とかの設定ができる)
構築が比較的容易

1.Architecture

まず、各ツールの役割は以下のようになっております。

①Prometheus : サーバ監視基盤
②Grafana : Prometheusのデータを可視化＆アラート検知/作成する
③Node_exporter : 被監視サーバのリソースデータをPrometheusへPushする

今回のアーキテクチャはPrometheus,Grafanaをそれぞれ一つのEC2インスタンスに導入し稼働させる構成としています。また監視対象のサーバはAPサーバ群(n台)としています。

2.Prometheus導入手順

環境

Amazon Linux 2 AMI (HVM), SSD Volume Type
Prometheus 2.3.2

今回はAWSに作成されたEC2インスタンスを利用して構築していきます。IPアドレスはそれぞれの環境に合わせて変更ください。

Prometheusの導入

Prometheusサーバにssh接続をし以下の手順で導入を行っていきます。

port 開放

プロメテウスサーバーはデフォルトだと9090ポートでlistenするので開放します。(解放済みの場合はスキップ)

firewall-cmd --add-port=9090/tcp --zone=public --permanent
firewall-cmd --reload
firewall-cmd --list-ports --zone=public

Prometheus Serverのインストール

wget https://github.com/prometheus/prometheus/releases/download/v*.*.*/prometheus-*.*.*.linux-amd64.tar.gz
tar zxvf prometheus-*.*.*.linux-amd64.tar.gz
mv prometheus-*.*.*.linux-amd64 promethus-server
cd promethus-server
cp prometheus.yml prometheus.yml.org
(ver.は任意)

解凍後のディレクトリに入りprometheus.ymlを編集する。- targets:以下に監視対象のサーバip:9100を追加していく

# my global config
global:
  scrape_interval:     15s # Set the scrape interval to every 15 seconds. Default is every 1 minute.
  evaluation_interval: 15s # Evaluate rules every 15 seconds. The default is every 1 minute.
  # scrape_timeout is set to the global default (10s).

# Alertmanager configuration
alerting:
  alertmanagers:
  - static_configs:
    - targets:
      # - alertmanager:9093

# Load rules once and periodically evaluate them according to the global 'evaluation_interval'.
rule_files:
  # - "first_rules.yml"
  # - "second_rules.yml"

# A scrape configuration containing exactly one endpoint to scrape:
# Here it's Prometheus itself.
scrape_configs:
  # The job name is added as a label `job=<job_name>` to any timeseries scraped from this config.
  - job_name: 'prometheus'

    # metrics_path defaults to '/metrics'
    # scheme defaults to 'http'.

    static_configs:
      - targets:
        - 'XXX.XXX.XXX.XXX:9100'

起動スクリプト作成（任意）

/usr/lib/systemd/system/prometheus.service

[Unit]
Description=Prometheus - Monitoring system and time series database
Documentation=https://prometheus.io/docs/introduction/overview/
After=network-online.target
After=network-online.target

[Service]
Type=simple
ExecStart=/usr/local/src/prometheus/prometheus-server/prometheus \
  --config.file=/usr/local/src/prometheus/prometheus-server/prometheus.yml \

[Install]
WantedBy=multi-user.target

起動

systemctl daemon-reload
自動起動設定
systemctl enable prometheus.service
起動
systemctl start prometheus.service

バイナリを直接起動する場合は以下

nohup ./node_exporter &

grepしてプロセスがスタートしていることを確認できたらOK

確認

http://<プロメテウスサーバーのIPアドレス>:9090/graphに接続すると
以下のようなページが表示されると思います。表示されたら、インストール＆初期設定完了

3.Node_exporter導入手順

被監視サーバにssh接続をし以下の手順で導入を行っていきます。

port 開放

デフォルトだと9100ポートでlistenするので開放します

firewall-cmd --add-port=9100/tcp --zone=public --permanent
firewall-cmd --reload
-- 確認 --
firewall-cmd --list-ports --zone=public
9100/tcp

Node Exporterのインストール

wget https://github.com/prometheus/node_exporter/releases/download/v0.16.0/node_exporter-*.**.*.linux-amd64.tar.gz
tar zxvf node_exporter-*.**.*.linux-amd64.tar.gz

起動スクリプト作成

[Unit]
Description=Node Exporter
Documentation=https://github.com/prometheus/node_exporter

[Service]
Type=simple
ExecStart=EnvironmentFile=/usr/local/src/prometheus/node_exporter/node_exporter $OPTIONS
Restart=always

[Install]
WantedBy=multi-user.target

起動

/usr/lib/systemd/system/prometheus-node-exporter.service

systemctl daemon-reload
-- 自動起動設定 --
systemctl enable prometheus.service
-- 起動 --
systemctl start prometheus.service

確認

http://<監視対象サーバーのIPアドレス>/metricsに接続すると
以下のようなステータスが記載されたページが開くと思います。

ブラウザでip:9100/metriksへアクセスしてみて以下のようにスクレイプ情報が表示されたら正常に動作しています。

4.Grafana導入手順①(インストール＆初期設定)

Grafanaサーバにssh接続をし以下の手順で導入を行っていきます。

インストール

wget https://dl.grafana.com/oss/release/grafana-6.2.5.linux-amd64.tar.gz 
tar -zxvf grafana-6.2.5.linux-amd64.tar.gz

起動

systemctl start grafana-server

バイナリを直接起動する場合は以下

nohup ./grafana &

grepしてプロセスがスタートしていることを確認できたらOK

アクセス

HTTPで3000番ポートにアクセスとあるので、ブラウザからやってみます。

初期ユーザ、パスワードのadmin/adminでログインします。

パスワードの変更

真っ先にやることは、デフォルトパスワードの変更です。画面左下のアイコンをクリックして、Preferencesを選びます。

次の画面で、Chenge Passwordを選択。新旧パスワードを入力して変更します。

データソースの登録

次にデータソースを登録していきます。

Deta Sourcesをクリックします。

名前を入力したらAdd data sourceをクリックしPrometheusを選択

Prometheusを選択する。

ここでhttp://localhost:9090のipはprometheusサーバのipへ変更

「Deta source is working」の表示が出たら設定完了

5.Grafana導入手順②(ダッシュボード初期設定)

データ連携が完了したら、次はデータの可視化を行うダッシュボードを作成していきます。ですが、予めダッシュボードの設計をしていない場合はテンプレートの利用がオススメです。

まず、目的に合わせてGrafanaのテンプレートを選定します。

「Grafana Labs」の「Downloads」にマウスオーバし、「Dashboards」をクリックしましょう。

すると上記のように、ダッシュボードの候補が表示されます。各ページに飛ぶとDashboard id表示されているのでコピーします。

そして、それをGrafanaのImportにidを入力しLoadするとダッシュボードが作成されます。

作成されたダッシュボードに移動し、データが監視データがトラッキングできていれば、完了です。

上記のようなサーバリソース情報が出力されていることが確認できます。

[DevSecOps] #2 まず見える化する

mizuki04 — Wed, 05 Aug 2020 19:17:38 +0000

1.まず見える化する

概要
開発と運用のサイロ化(サイロ化とは、企業のある部門が、他の部門と情報共有や連携などをせずに独自に業務を遂行し、孤立した状態を表す語)を生む原因として、そもそもやりたくない作業（障害復旧とかメンテナンス作業とか）を押し付けあうことが原因となるので、それを少なくしたい。そんな発想が生まれる。見える部分に関しては問題であると認識できるが、見えない部分に関しては言うまでもなく。なので、稼働しているシステムがどのように動作しているかを逐一把握していく必要がある。そうなった時にモニタリング環境を整備する必要がある。
具体的に満たしたい条件

・コストがかからないこと
・応答が早い事
・設定、メンテナンス作業が楽なこと
・機能が豊富なこと
・デザインが美しいこと（これ大事）

上記を踏まえて技術選定を行った

上記を踏まえるとSoundCloud社がリリースしているPrometheusと言う監視サービスを採択する事に決めた。

やはり一番のメリットとしては、コストがOSSで無料であることとServiceDiscovery機能によって同一アカウントに紐づくEC2などを自動で検知してくれるスケーラビリティが優れている事として使用を決めた。

[Prometheusの概要]（以下抜粋）
Prometheus は、サーバのリソース状況やソフトウェアの統計情報といった各種メトリックスを収集して監視を行うモニタリングシステムです。ロギングやトレーシングを行うといった多用途のものではなくメトリックス収集に特化しているモニタリングシステムで、人気が高まりつつあるモニタリングシステムです。

もともと SoundCloud 社によって開発されたツールで、現在では、Cloud Native Computing Foundation によってメンテナンスされており、クラウドや Kubernetes 環境で利用されるケースが多いのも特徴です。

メリット引用

次は構築について記載致します。

[DevSecOps] #1 ビジネスを加速する文化的処方箋

mizuki04 — Wed, 05 Aug 2020 18:37:35 +0000

DevSecOPSとは

1.概念

「development」(開発)と「operations」(運用)、その言葉が明確に分けられ、役割の違いを表しているように。組織内の構造が分かれている事を伴って、必要のない摩擦や作業(組織の大小に関係なく、分かれていることが原因で責任の所在が不明瞭になる事)を生んでいるパターンがしばしば見受けられる。その分断≒細胞壁を破り、ビジネスの方向性によって柔軟に形を変えられる有機体を目指すために、この言葉が生まれたと理解している。また、このような名前付を行う事によって文化となり、ToDoを明確化し、エンジニアリングの価値を実現するスピードを早める考え方であると捉えている。この活動を通して、

・チーム内の透明性が増し、チーム内に信頼が生まれる。

・実際にダメージの大きいミスをする前に、それを防ぐ方法をチームメンバに伝えられる。

・新しい問題の解決に使える時間が増え、より本質的な活動に時間を多く割ける。

・そもそも、新しいプロダクトを設計するにあたって長期的に発生するであろう技術的な負債を回避できる。

上記のような満足があるという認識。

一般的に知られているのは、何か作業を自動化するであったりとか、新しいツールを導入するということが表に出てくることが多いが実際の根本的な課題は、分断されていた状態であったためお互いに理解しあう為のスタンスを持つまでに少しリハビリが必要な事だったりするんじゃないかと思ってる。そしてそのような構造が時間と共に大きくなっていけばいくほど変えづらい物になるので本当に初期に取り組むべき活動だと考えている。

2.具体例

実際に上記の文化がない状態だったとしたらどんな現状が起こるのかを書いてみる

運用面 :
- 緊急で入る運用業務に時間が取られ定時過ぎてから「自分の案件」に着手する...
- 肥大化したリソースの管理を手動で行うため、運用ミスで重大な毀損の事故を起こす
- secondary繋げ忘れて参照できない問い合わせが来る
- primaryが容量が100%でDBがdown
- slow queryによって、その他のプロセスがつまる
- 多数のサーバーの脆弱性対応で一日中工数が奪われる
- そもそもセキュリティ領域の作業などが属人化しているので開発側が分からない
開発面 :
- 複数の案件が同時に走るため、マージ後のテストのし忘れによる事故発生
- 密結合なサービスに機能追加したので、全てに影響が出てしまいテストケース増
- 新規案件の影響範囲や工数を適切に見積もることができる人材がいない
- UnitTestがなくて手動による確認を行う。結果考慮漏れがあり事故

その結果どうなるのか

企画が提案する案件は、非常に工数が意識されたその場しのぎの案件が走る
そもそも既存のソースコードが汚いので。。という妥協
運用が属人化して、新規参入者が活躍しずらい組織に
問い合わせやバグなどの発見が非常に困難

上記の事例をあげるだけでも枚挙に暇がない。

3.上記の文化を実現するために

実際にアクションを起こした内容について[DevSecOps]のタグと共に具体的に行ってきた事の詳細を発信しようと思う。