kakakakakku blog

Weekly Tech Blog: Keep on Learning!

CPU / メモリ / ディスクに負荷をかける stress コマンド

最近 stress コマンドを使って,サーバに負荷をかける方法を紹介する機会があり,よく使っているのに今までブログに書いていなかったなと気付き,今回まとめることにした.CPU に負荷をかけるだけなら yes > /dev/null をコア数に合わせて並列実行すれば良いけど,stress コマンドならメモリとディスクにも負荷をかけることができるので,シナリオのバリエーションを増やすことができる.

インストール

検証環境として CentOS を使った.

$ sudo yum install stress

$ stress --version
stress 1.0.4

共通オプション

以下のような共通オプションが用意されている.よく使うのは --timeout で,秒数を指定して負荷をかけることができる.他はあまり使ったことがないかも.

  • -t, --timeout : 負荷をかける秒数を指定する
  • -n, --dry-run : 実際に負荷をかけず,期待値を確認する
  • -q, --quiet : 標準出力を抑制する
  • -v, --verbose : 標準出力にデバッグ情報まで表示する

CPU に負荷をかける

CPU に負荷をかける場合は --cpu オプションを使う.引数にコア数を指定するので,/proc/cpuinfo あたりを見て負荷を調整する.以下は,10秒間 CPU に負荷をかけて dstat で確認している.

$ stress --cpu 2 --timeout 10

$ dstat -c
----total-cpu-usage----
usr sys idl wai hiq siq
  0   0 100   0   0   0
  0   0 100   0   0   0
 73   0  27   0   0   0
100   0   0   0   0   0
100   0   0   0   0   0
100   0   0   0   0   0
100   0   0   0   0   0
100   0   0   0   0   0
100   0   0   0   0   0
100   0   0   0   0   0
100   0   0   0   0   0
100   0   0   0   0   0
 26   0  74   0   0   0
  0   0 100   0   0   0
  0   0 100   0   0   0

メモリに負荷をかける

メモリに負荷をかける場合は --vm オプションを使う.1 VM あたりのメモリサイズはデフォルトで 256MB になっているので,変更する場合は --vm-bytes 512M のように --vm-bytes オプションと併用する.また,デフォルトの挙動では「メモリ確保 → メモリ解放を繰り返す」ようになっている.

$ stress --vm 1
$ stress --vm 2
$ stress --vm 2 --vm-bytes 512M

以下は,10秒間メモリに負荷をかけて dstat で確認している.used の値が「増えて → 減って」を繰り返していることがわかる.

$ stress --vm 2 --timeout 10

$ dstat -m
------memory-usage-----
 used  buff  cach  free
97.9M 19.2M  442M 3148M
97.9M 19.2M  442M 3148M
 328M 19.2M  442M 2918M
 158M 19.2M  442M 3088M
 396M 19.2M  442M 2850M
 137M 19.2M  442M 3109M
 445M 19.2M  442M 2801M
 194M 19.2M  442M 3051M
 500M 19.2M  442M 2745M
 245M 19.2M  442M 3000M
 545M 19.2M  442M 2700M
 312M 19.2M  442M 2934M
98.4M 19.2M  442M 3147M
98.4M 19.2M  442M 3147M

逆に「メモリ確保を維持する」場合には --vm-hang オプションと併用する.--vm-hang オプションには維持する秒数を指定することができ,0 を指定すると無期限に維持する.以下は,10秒間メモリに負荷をかけて,確保サイズを 512MB で維持している.

$ stress --vm 2 --vm-hang 0 --timeout 10

$ dstat -m
------memory-usage-----
 used  buff  cach  free
 105M 21.2M  444M 3137M
 105M 21.2M  444M 3137M
 617M 21.2M  444M 2625M
 617M 21.2M  444M 2625M
 617M 21.2M  444M 2625M
 617M 21.2M  444M 2625M
 617M 21.2M  444M 2625M
 617M 21.2M  444M 2625M
 617M 21.2M  444M 2625M
 617M 21.2M  444M 2625M
 617M 21.2M  444M 2625M
 617M 21.2M  444M 2625M
 105M 21.2M  444M 3136M
 105M 21.2M  444M 3136M

ディスクに負荷をかける

stress コマンドではディスク(書き込み)に負荷をかけることができる.その場合は --hdd オプションを使う.デフォルトの挙動では「書き込み → 削除を繰り返す」ようになっている.書き込みサイズはデフォルトで 1GB になっているので,変更する場合は --hdd-bytes 2G のように --hdd-bytes オプションと併用する.あとは dstat -r で IOPS あたりを確認する.

$ stress --hdd 1 --timeout 10
$ stress --hdd 2 --timeout 10
$ stress --hdd 2 --hdd-bytes 2G

まとめ

  • サーバに負荷をかける場合は stress コマンドが便利
  • CPU だけではなく,メモリとディスクにも負荷をかけることができる

ストレッチ + リフレクション + エンジョイメント /「経験学習」入門を読んだ

「経験学習」とは,経験から学び成長することで,例えば,難易度の高かった仕事/個人プロジェクトなど,日々何かしらの「経験学習」をしていると思う.自分自身が今後どのように「経験学習」をしていけば良いのか,そして技術講師として学びを伝えるためにどんなことを意識すれば良いのか,そのあたりを知るために,今回『「経験学習」入門』を読んだ.本書の導入部分にも書いてあるけど,もっと成長したい人,育成に悩んでいる人,チームマネジメントをしている人などが読者層かなと.

「経験学習」入門

「経験学習」入門

経験学習モデル

組織行動学者のコルブによって提唱された「経験学習モデル」とは,以下の学習サイクルを繰り返しながら成長するという理論で,個人的には「省察(言い換えると,リフレクション,振り返り)」が特に重要だと思う.

  • 経験 (Concrete Experience)
  • 省察 (Reflective Observation)
  • 概念化 (Abstract Conceptualization)
  • 実践 (Active Experimentation)

ちなみに,最近読んだ「教育研修ファシリテーター」にも「経験学習モデル」の話が載っていて,また出たー!感がある.

kakakakakku.hatenablog.com

3要素

本書では「経験から学ぶ力のモデル」として,以下の3要素が挙がっていた.

  • ストレッチ(挑戦)
  • リフレクション(振り返る)
  • エンジョイメント(楽しむ)

常に挑戦するというのは重要なことだけど,ストイックすぎても続かないため,好奇心を持ち,楽しむことも大切だという意味で「エンジョイメント」が3要素の中に挙がっているのは良かった.そのためには,淡々と仕事を進めるのではなく「なぜこの仕事が必要なのか?」という本質を考えることが必要だと書かれていた.また「内発的動機」に関しても言及があった.「内発的動機」に関しては「モチベーション3.0」に詳しく書いてある.仕事/メンタリング/セルフコーチングなど,どんなシチュエーションでも「ストレッチ + リフレクション + エンジョイメント」を意識すると良さそう.

kakakakakku.hatenablog.com

70:20:10 の法則

成長を決める要素の比率として「70:20:10 の法則」が紹介されていた.

  • 70% : 直接経験
  • 20% : 間接経験(フィードバック)
  • 10% : 間接経験(読書/研修)

比率に異論はないけど,個人的には「フィードバックをもらうこと」をとても大切にしていて,むしろ「フィードバックをもらえなくなったら成長は止まる」とも思っているので,工夫次第では「20%」以上の価値がある要素になると思う.本書には「ポジティブ・フィードバック」も「ネガティブ・フィードバック」もどちらも言及があった.「ポジティブ・フィードバック」は,ただ褒めるだけではなく,良いことを良いと適切に伝えることができる点がポイントで,「ネガティブ・フィードバック」は異なる価値観を気付かせることがポイントだと思う.本書にも「批判にオープンになる」という話があって良かった.

能力的成長と精神的成長

成長を分類すると「能力的成長」「精神的成長」に分類できると書いてあった.特に「精神的成長」とは,仕事に対する信念/価値観が変わり,自己中心的なものから,他社/社会と繋がり影響を与えていくようになるということで,組織を客観的に見て,組織の課題解決に向き合ったりするのは「精神的成長」に分類されるのかもしれないと感じた.

まとめ

『「経験学習」入門』を読んだ.内容的にはそこまで新しいものはなく,これまで読んできた「自己啓発」関連の本と「メンタリング」関連の本とカブっている部分も多かったけど,改めて「経験学習」のサイクルを学び直せたのは良かった.どこまでもストイックに挑戦していく性格なので,よりエンジョイメントの比率を高くし,もっと間接経験(フィードバック)をもらいながら成長できるように頑張りたいなと!

依存パッケージを更新するサービス「Dependabot」で Dockerfile の更新をチェックする

Dependabot は依存パッケージの更新を定期的にチェックし,更新があった場合にプルリクエストを作成してくれるサービスで,現時点で「Ruby, JavaScript, Python, PHP」など,多くのプログラミング言語がサポートされている.他にも「Go, .NET」などは BETA & ALPHA 版でサポートされている.依存パッケージの更新が重要なのはわかっていても,月に1回など,定期的なイベントとして実施しているチームも多いと思うので,Dependabot を使うメリットがある.

dependabot.com

Dependabot 以外だと GreenkeeperTachikoma.io を使っているチームもあるし,CircleCI などと組み合わせて独自実装で実現しているチームもある.あえて自動化はせず「チームメンバーの教育目的で手動で依存パッケージを更新する」というチームの話も聞いたことがある.

Docker サポートとは?

Dependabot がサポートしているプログラミング言語の中に「Docker」があり,具体的に何をしてくれるんだろう?と興味があったので,実際に試してみた.結論から言うと「Dockerfile のベースイメージに更新があったら Dockerfile を更新するプルリクエストを作成してくれる機能」だった.これは便利では!?

f:id:kakku22:20181012190403p:plain

インストール & 設定

Dependabot は GitHub Marketplace からインストールし,次にリポジトリを登録しておく.パブリックリポジトリなら無料で使えるので,すぐに試すことができる.あとはチェック設定をするだけで,今回は以下のように Dockerfile を管理しているリポジトリを登録してみた.Docker の場合,以下のオプションを追加で指定することができる.

  • Directory (optional)
  • Target branch (optional)
  • Automatic PR merging
    • Runtime dependency PRs to merge automatically
    • Development dependency PRs to merge automatically

なお,スケジュールは以下の3種類から選ぶことができる.

  • Daily updates
  • Weekly updates
  • Monthly updates

f:id:kakku22:20181012190354p:plain

プルリクエスト

以下のように alpine:3.7alpine:3.8 に更新するプルリクエストが作成された.常に最新バージョンを確認しているわけではないので,Dependabot が定期的にチェックしてくれるのは便利だった.常に最新という意味で alpine:latest を指定しているのであれば,プルリクエストは出ないと思う.

github.com

f:id:kakku22:20181012190342p:plain

ChatOps

Dependabot は ChatOps に対応しているので,プルリクエストのコメントで以下のようなメンションをすると,トリガーすることができる.今回は自分でプルリクエストをマージするのではなく @dependabot merge を使ってマージした.

  • @dependabot rebase
  • @dependabot merge
  • @dependabot cancel merge
  • @dependabot reopen
  • @dependabot ignore this [patch|minor|major] version
  • @dependabot ignore this dependency
  • @dependabot use these labels
  • @dependabot use these reviewers
  • @dependabot use these assignees
  • @dependabot use this milestone
  • @dependabot badge me

Flexible monorepo support

サイトには Flexible monorepo support と書いてあるけど,実際にディレクトリ / で登録しようとすると Repo must contain a Dockerfile. とエラーが出て使えなかった(なぜ?).今回はディレクトリごとに登録をした.

Using a monorepo? No problem - you can specify one or many directories within a repo for Dependabot to look for Dockerfiles in.

まとめ

  • 依存パッケージの更新を定期的にチェックしてくれる Dependabot は便利
  • Dependabot は Dockerfile もサポートしているので,ベースイメージの更新をチェックできる
  • すごく便利なので Dependabot がもっと人気になれば良いな!

最新バージョン Redash v5 をすぐに試せる「Redash ハンズオン資料」

Redash v4 のリリースから約5ヶ月,正式に Redash v5 がリリースされた 🎉🎉🎉

blog.redash.io

Redash v5 とは?

約1ヶ月間のベータ期間を経て,現在は Redash v5.0.1 が最新バージョンになっている.デザインの大幅な変更があった v4 から,順当に便利になっていると感じている.特に以下は個人的な目玉機能と言える.

  • クエリに「お気に入り登録」「タグ登録」をできるようになった
  • ダッシュボードに「お気に入り登録」「タグ登録」をできるようになった
  • ユーザーを無効化できるようになった
  • パラメータで日付の範囲指定ができるようになった
  • クエリ編集画面でレイアウトを変更するショートカットが使えるようになった
    • Alt + D : テーブル一覧とクエリエディタを非表示にする
    • Alt + Shift + D : テーブル一覧を非表示にする

詳細な Changelog は GitHub のリリース情報にまとまっている.

Redash ハンズオン資料 v5 対応

そして今日「Redash ハンズオン資料 v5 対応」をリリースした 🎉🎉🎉

github.com

主な変更点を以下にまとめる.

  • 全てのスクリーンキャプチャを撮り直した
  • 新コンテンツ
    • クエリの「お気に入り登録」「タグ登録」
    • ダッシュボードの「お気に入り登録」「タグ登録」
    • ユーザー追加とユーザー無効化
  • MySQL の Docker Image を kakakakakku/mysql-world-database:5.7 に変更した

Docker Image に関して,今まで使っていた kakakakakku/mysql-57-world-database は,バージョンごとにイメージ化していて,さらに Docker Hub のアップロードを手動でやっていたので,運用面で課題があった.今回から使うことにした kakakakakku/mysql-world-database:5.7 は,バージョンごとにイメージタグを切って,さらに Docker Hub の AUTOMATED BUILD を使っている.既に MySQL 8.0 も用意しているので,試すこともできる.

github.com

Redash v4.0.2

ちなみに,長らく最新バージョンとなっていた Redash v4.0.1 に Google OAuth 関連のセキュリティ問題が発覚し,急遽 Redash v4.0.2 がリリースされた経緯がある.詳しくは Arik のブログに書いてある.

https://blog.redash.io/important-redash-security-update-%EF%B8%8F-2fb8134ca689blog.redash.io

それに伴って,Redash ハンズオンも v4.0.2 に対応してある.v4 でハンズオンを試す場合は,是非 v4.0.2 を使って頂ければと!

まとめ

「Redash ハンズオン資料」を使って Redash v5 を学ぼう!

github.com

関連記事

kakakakakku.hatenablog.com

kakakakakku.hatenablog.com

コンテナのデザインパターンを学べる論文「Design patterns for container-based distributed systems」を読んだ

2016年に USENIX Conference で発表された論文「Design patterns for container-based distributed systems」を読んだ.タイトルの通り,コンテナのデザインパターンがまとまっていて,これからコンテナ設計をする人も,既にコンテナを運用している人も,デザインパターンを学べるのは価値があると思う.一部ミスリードをしているかもしれない.

論文も公開されている.

パターン一覧

  • Single-container management patterns(コンテナ管理用の単一コンテナパターン)
  • Single-node, multi-container application patterns(シングルノードでのマルチコンテナパターン)
    • Sidecar pattern(サイドカーパターン)
    • Ambassador pattern(アンバサダーパターン)
    • Adapter pattern(アダプターパターン)
  • Multi-node application patterns(分散システムのためのマルチノードでのパターン)
    • Leader election pattern(リーダー選出パターン)
    • Work queue pattern(ワークキューパターン)
    • Scatter/gather pattern(スキャッター/ギャザーパターン)

Single-container management patterns(コンテナ管理用の単一コンテナパターン)

  • コンテナは境界を提供するため,アプリケーションだけではなく,管理用(オーケストレーション)としても使える
  • コンテナを止めるときに SIGKILL シグナルを送り強制停止するのではなく,SIGTERM でコンテナの終了処理を実行できるようにする
  • "upward" : 監視メトリクスやプロファイリング情報やヘルスチェックを取得することができる(コンテナに対する管理)
  • "downward" : 優先順位の高いタスクのために,優先順位の低いタスクを終了することができる(コンテナ内部のプロセスに対する管理)

Single-node, multi-container application patterns(シングルノードでのマルチコンテナパターン)

Sidecar pattern(サイドカーパターン)

  • メインコンテナを拡張し,強化する
  • ウェブサーバがメインコンテナだとすると,ホスト側のディスクを読むログ保存コンテナはサイドカーになる
  • 他にも Git リポジトリからコンテンツを取得して,ホスト側に定期的に同期するサイドカーもある

個人的に経験があるのはログ収集用に使う Fluentd コンテナで,まさに同じユースケースと言える.サイドカーが異常になった場合も,メインコンテナに影響しないというのがポイントだと思う.

Ambassador pattern(アンバサダーパターン)

  • メインコンテナが外部とコミュニケーションをするときのプロキシになる
  • 例えば Memcached プロキシの twemproxy など
  • メインコンテナは localhost の Memcached に接続するように見えるけど,実際にはアンバサダーがプロキシをしている

ロードバランサーにも似ていて,外部とコミュニケーションをするという関心事をアンバサダーにオフロードしているのがポイントだと思う.他にも Microservices を構築するときに考える Service Mesh (Envoy / Linkerd) での Circuit Breaker もアンバサダーに分類されるかな?

Adapter pattern(アダプターパターン)

  • アンバサダーとは異なり,外部とのインターフェースを標準化する
  • システム内の全てのコンテナが同じモニタリングインターフェースを持つ

海外旅行で使う電源変換アダプタのイメージと言える.具体的には Prometheus のようなプル型のモニタリングシステムと相性が良さそう.

f:id:kakku22:20180923120447j:plain

(構成図を作った)

Multi-node application patterns(分散システムのためのマルチノードでのパターン)

Leader election pattern(リーダー選出パターン)

  • 分散システムのよく知られた課題に「リーダー選出」がある
  • 複数のノードに分散したコンテナ同士で通信をする
  • リーダー選出の実装は複雑になることが多いので,実装言語を気にせずコンテナを再利用することができる

今まで経験があるのは Consul のリーダー選出(内部的には Paxos?Raft?)ぐらいで,その他は経験がないけど,リーダー選出という複雑な部分をコンテナに押し込めるのはメリットがあると思う.ただし,論文にもあまり詳細は書かれていなかった.

Work queue pattern(ワークキューパターン)

  • リクエストを非同期に処理するため,一度キューに入れてからワーカーコンテナで処理をする
  • ワーカーコンテナは直接キューに接続するのではなく,コーディネーターコンテナからメッセージを受ける

読んでいるときに「一般的なキューとワーカーの組み合わせと何が違うんだろう?」と疑問だったけど,キューからメッセージを受ける部分もコーディネーターにオフロードすることで,キューの種類が変わっても(例えば Kafka, SQS, ActiveMQ, RabbitMQ など)ワーカーは影響を受けない構造になっていて,納得できた.個人的に1番学びのあるデザインパターンだった.

f:id:kakku22:20180923120508j:plain

(構成図を作った)

Scatter/gather pattern(スキャッター/ギャザーパターン)

  • ルートノード or 親ノードにリクエストを送る
  • そこから子ノードに並行してリクエストをファンアウトする
  • 子ノードの結果をマージするマージコンテナもある

Scatter(散布)と Gather(収集)という意味で,具体的な例で言えば MapReduce と同じ構成と言える.

f:id:kakku22:20180923120518j:plain

(構成図を作った)

まとめ

  • 論文「Design patterns for container-based distributed systems」を読んだ
  • 論文などアカデミックな情報源から学べることも多いので,継続的に読んでいきたい
  • これからコンテナ設計をする人も,既にコンテナを運用している人も,デザインパターンを学べるのは価値がある
  • 最近はコンピュータサイエンスの論文の解説が聞けるポッドキャスト「Misreading Chat」がお気に入りでずっと聞いている

misreading.chat

Cloud Computing Concepts, Part 1

Coursera で「Cloud Computing Concepts, Part 1」という講義を受講することができる.これは「分散システム」を学ぶ講義になっているので,興味がある人がいたら是非オススメしたい.僕が受講したときのメモは全て以下の記事にまとめてある.

kakakakakku.hatenablog.com