構築中。

名古屋のITインフラお守り係です。ITイベントへの参加記録などを残していきます。

JAWS-UG 浜松 AWS 勉強会 2021#2(2/26)

今回、初めて発表側で参加しました。

jawsug-hamamatsu.doorkeeper.jp

JAWS-UG 浜松では、JAWS-UG 名古屋とは違い、

  • Expert Online
  • 通常の勉強会

を(ほぼ)交互に開催しているようで、これまでに参加した通常回では主に「作ってみたサービスの紹介」が多い印象でした。

※今回も「Shrimphouse」など面白い話がいくつかありました。


そういうこともあって発表者として手を挙げるか少し迷ったのですが、つい先日 AWS 東京リージョンで AZ 障害があったばかりだったので、1 年半前の JAWS-UG 名古屋での発表をアップデートする形で発表してみました。

speakerdeck.com

時間の関係で巻きでしゃべった(それでも 23 ~ 24 分くらい掛かってしまった)のでうまく意図が伝わったかどうかわかりませんが、何かの参考にしていただければ幸いです。

なお、本日 2021/03/02 に AWS 大阪リージョンがフルリージョン化したので、それに合わせて資料に一部手を加えました。

JAWS-UG 名古屋 いろんなパフォーマンスを学ぶ(1/28)

先月に引き続き登壇参加です。

jawsug-nagoya.doorkeeper.jp

今回は、参加者募集が始まっているのに気付かずにいたところ、JAWS-UG 名古屋の杉本さんにお声掛けいただきました。


話したネタはこれ↓です。今回は画面操作の時間があったので、スライドだけを見ても話のつながりが分かりづらいのですが。

(一応、動画のアーカイブはあるらしいです。)

speakerdeck.com

例によって(?)普段どおりの RDS / Aurora ネタですが、直感的に分かりそうで、実は細かいところが分かりづらいパフォーマンスインサイトの話でした。

分かりづらい点としては、以下のようなものがあります。

  • 「待機イベント」の概念
    • 対象とする RDBMS によって「イベントをどう区分するか」が違う
  • すべての待機イベントを集計しているわけではない
    • 対象時間(1 秒・1 分など)における上位 9 件までを集計している模様(それ以下は省略?)
  • RDBMS の待機イベントとしては存在しない「CPU」という区分とその意味
    • マニュアルでは明確な説明はないが、おそらく「全体の処理時間 - 個々の待機イベント時間 = CPU で計算している時間」と捉えたものだと思う
  • 表示期間(Start to End)における上位 9 件と対象時間(グラフ 1 本分= 1 秒・1 分など)における上位 9 件が違う場合の表現
    • 個々の時間の待機イベントが一部表示されないので、合計値がずれる
    • これのせいで、上に書いた「全体の処理時間 - 個々の待機イベント時間 = CPU で計算している時間」という関係性も、グラフ上は正確に表現されなくなる

こうして箇条書きにしたものを読んでも意味が分かりづらいと思いますので、是非、APICLI v1)を使って、

  • 60 秒間のデータを、粒度 60 秒で取得(1 組分のデータ)
  • 60 秒間のデータを、粒度 1 秒で取得(60 組分のデータ)

や、

  • 60 分間のデータを、粒度 60 分で取得(1 組分のデータ)
  • 60 分間のデータを、粒度 1 分で取得(60 組分のデータ)

などを見比べて、集計値にどのような違いが出るかを比較してみてください。イメージが湧くと思います。

ちなみに時間は 5 分オーバーしましたが、事前に「今回は予定セッションが少ないので時間は超過しても良いです」という話を伺っていたので、無暗に話を省略することは避けました。


このあたりの説明に終始してしまったため、肝心の

  • パフォーマンスインサイトを使って何を読み取りどう性能改善していくか?

というポイントが説明できなかったことが悔やまれます。

※基本的には SQL(文)の上位にランクインしたものからチューニングしていくのが良いのですが(SQL(文)の書き替えによりアクセスパスを見直して平均アクセス行数を減らす、無駄に多く実行されている SQL(文)の実行頻度を減らすようアプリケーションを改修する、など)、特に更新系の SQL(文)については見方が難しいところがあるので注意が必要です(トランザクションを使っている場合は更新処理そのものの負荷が COMMIT (または END )文に集中するので INSERTUPDATEDELETE 文がランク上位に入りづらい=可視化されにくい、など)。


その他のセッションでは、エイチームさん(の一部?)の ECS 環境の構築ポリシーや、AWS からテンプレート提供されている分散負荷テストツールの実行イメージ、機械学習をスポットインスタンスで実行するときのお勧めインスタンスが分かったり…という感じで地味に収穫がありました。

実参加者が少なかったのがちょっと残念でしたが。

吉祥寺.pm25【オンライン】(1/19)

初のトーク参加でした。

kichijojipm.connpass.com


ずっとトーク枠が空いていることが気になっていて、かといって「一句」が思い浮かばず…そんな中われらが yoku0825 さんの

を見かけて(残念)、これは自分が穴を埋めるしかない!と奮起勘違いして悩むこと数日。

年初、

hmatsu47.hatenablog.com

の最後のところで「実践ベースのアウトプット」を掲げた以上、まずは実務の中から…と考えたところから「実体験した怖い話」を思い出し、なんとか一句が生まれました。


話の内容としては、

  • 継続的デリバリーモデル
  • OLTP + OLAP = HTAP
  • レガシーなシステムでのクラウドとの付き合い方

という、一見関係無さそうなものを取り上げたのですが、実際に思い浮かんだのは逆順でした(「一句」からの逆算パターン)。

  • 年末年始は自社サービスで使ってるクラウド基盤起因のトラブル対応が大変だった
    • 一句できた
    • すごいニッチなトラブルだったけれど、もしかしたら誰か同じトラブルに当たるかもしれないから一応情報共有しておこう

   ↓

   ↓

  • MySQL といえば 8.0 は継続的デリバリーモデルだな
    • ついでに薄い本の宣伝でもしておくか

   ↓

  • 継続的デリバリーといえば、CentOS Stream があった
    • そういえば去年の年末に CentOS 8 終了→CentOS Stream に一本化で世間がざわついていたな

実際のところ(CentOS がどうかは置いておいて)MySQL 8.0 が継続的デリバリーモデルを採用したのは Oracle Cloud 上で MySQL をマネージドサービスとして提供することを見込んでのことだったはずなので、「クラウド=サービスが自動的に進化する」と「サーバソフトウェア・ミドルウェア等が継続的デリバリーモデルを採用する」は割と関連のある話ですね。

結果的に「おまけ」でねじ込んだ「MySQL 8.0 の薄い本」の話が決め手(?)になり、ベストトーク賞までいただくことができました!(ありがとうございます!)


「ニュー・ノーマル」の昨年は、環境の変化とそれに合わせた行動パターンの変化が目立った 1 年でしたが、個人的には特に強いストレスを感じることなく「至って普通」に過ごせたと感じています。

振り返ってみると、「環境が変わっても自分は自分。中身まで急に変わるわけではない」という意識が根底にあって、そのおかげで必要以上に振り回されずに済んだのかな?と。

まあ、元々「引きこもり耐性」は高いほうだったとは思うのですが(ここ数年の極端にアクティブな行動のほうが異常だったのかもしれない)。


さっぴーさんの勉強会のニュー・ノーマルの話もすごくわかる話でしたし(とはいえ地方民としてはオンライン化で参加できる勉強会が 1 桁増えたのでありがたい限りなのですが)、そーだいさんのノベルティの話も、「今は配布が大変だよな…」という点でわたしの「MySQL 8.0 の薄い本」(元々、オフラインの勉強会で無料配布していた)に通じるものがありました。


個人的にはいまの流れがしばらく続いても平気ではありますが、1 年半くらい後には、東京を含め全国各地を飛び回れるようになると嬉しいです。