構築中。

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

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 で計算している時間」という関係性も、グラフ上は正確に表現されなくなる

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

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

や、

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

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

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

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

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

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

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

その他のセッションでは、エイチームさん（の一部？）の 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 年半くらい後には、東京を含め全国各地を飛び回れるようになると嬉しいです。

2021 年の目標、やること、やりたいことなど

雑記

12/31 に昨年のふりかえりを書いたので、今日は今年の目標・やること・やりたいことなどを書いていきます。

hmatsu47.hatenablog.com

お仕事編

以下の 3 つを中心に進めていきます。

（本当はほかにもいくつかあるのですが、わたしが頑張ってしまうと中長期的に見てかえって組織に悪影響を与えかねないので、ほかの件はほどほどにやっていきます。）

なお昨年、終盤になって突如転職話が持ち上がったのですが結果としてその話は無くなったので、とりあえず腰を落ち着けてやっていきます。

AWS アカウントのサービス別分離（続き）

昨年、自社のメインサービスのプロダクト環境の分離を終えたので、今度は元のアカウントに残った別サービスの整理を行います。

バックアップサイトの強化

これまでデータバックアップ用に AWS の大阪ローカルリージョンを使ってきましたが、大阪リージョンがフルリージョン化するのに合わせて、サイト全体のバックアップ機能の実装を進めていきます。

スケールを意識したアーキテクチャの変更

ここが最大のポイントです。自社のメインサービスの現状のアーキテクチャはかなり古く、このままスケールアウト＆スケールアップ作戦で「延命」を図っても、ピーク時の負荷が現在の倍程度に達するとリクエストを捌ききれなくなる可能性があります。

（まあ今後の AWS プラットフォームの性能向上によって「倍」が「2.5 倍」「3 倍」になる可能性はあるでしょうが、一方で 3 年前の Spectre / Meltdown 対策のような「一時的であれ性能が 1/2 に」という事象が発生しないとも限らないですし。）

サービス全体の規模も大きくなり全体を一度にリニューアルする作戦は取りづらくなっていますし、時間を掛けて綿密な計画を練って…という余裕も残されていないので、今年は全体に与える影響度を見ながら部分部分で試行錯誤しながら進めていくことになりそうです。

個人活動編

昨年の振り返りで、

やっぱり「実践を伴うアウトプット」は大事ですね。

と書きました。

昨年まではインプットもアウトプットも量を優先に進めていましたが、今年は

  • 昨年よりは質を重視する
  • 「実践ベースのアウトプット」を意識する

スタンスで行く予定です。

Qiita・ブログなど

本数としては、アドベントカレンダーを除いて月 2 ～ 3 本ペースで。

Qiita は単純な「やってみた」（軽く試してみた）記事以外の、実践によって得た知見を元にした記事を増やして行きたいところです。

イベント・勉強会

今年もほぼオンライン開催だと予想しています。

東京都から政府に対し緊急事態宣言発出を要請しているようですが、これは「何としてもオリンピック開催を」ということでしょうね（他の首都圏 3 県はともかく）。

個人的には、オリンピックは開催するにしても無観客の線が濃厚と考えていますが、最終決定（開催か中止か、開催ならどんな形になるか）までの紆余曲折のあおりを受けてコロナ収束の見通しが（年内には）立たなくなり、一般のイベントはリアル開催が更に難しくなるでしょう。

地方民としては、昨年に続いて参加できるイベントが多くなりそうなので歓迎すべき面もあるのですが、惰性で参加を続けてしまうと「オンライン勉強会の参加疲れ」になってしまうので、わたし自身は昨年より対象を絞り込んで参加しようと考えています。

また、登壇についても、これまでは「身のまわりの人の登壇ハードルを下げる」ことを意図して軽いテーマを多めにしていたのですが、今年は「登壇の半分は内容重視」を意識していきます（結果として、回数は減るはず）。

Local IT Meetup（主催イベント）

note.com

こちらは昨年開催できなかったので今年はぜひ開催を…と言いたいところですが、

  • 主催メンバーの活動に無理が生じないか？
  • オンライン開催のメリットを見出せるか？

を十分考慮して進めていきたいです。

MySQL 8.0 の薄い本

今年は MySQL 5.6 のサポート終了が決まっていますが、それに合わせて MySQL 9.0（DMR）がやって来るのかどうなのか…？

いまのところ「MySQL 8.0 の薄い本」の改訂は続けていく予定ですが、四半期ごとのマイナーバージョンアップ全てに対応するかどうかはわかりません（昨年も 8.0.21 は見送りましたし）。

情報処理安全確保支援士（登録セキスペ）

ほどほどに進めていきます。

まとめ

昨年はコロナの影響もあって、わたし自身大きく活動パターンが変わりました。活動量は増えましたが、中身が薄くなった気がします。

今年は昨年の反省を受けて、「腰を据えて活動する」ことを意識していきたいです。

また、「実践ベースのアウトプット」に向けて、（知見の公開に制約がある）自社サービスだけでなく、「自分のためのサービス」を個人で作って運用…にも挑戦しようと考えています。