oranie's blog

旧:iをgに変えると・・・なんだっけ・・・

MySQLに初めてINSERTするとアクセスが発生するファイルは何かという質問をどう調べるのか

yokuo825さんのカッコいいインタビュー記事を

t.co

読んで、この部分ですね

──例えばどのような話をしましたか? 
 「インストールされたばかりのMySQLがあるとして、特定テーブルに1件のレコードを最初にINSERTした場合、アクセスが発生するファイルとその理由をすべて教えてください」と質問されたのを覚えています。 

具体的にどのような理由でどのファイルにアクセスするか、一連の流れを片っ端から答えていくと、彼らがすごく楽しそうにしてくれて。「そうか、LINEの環境だと○○の設定が最初から○○になっているので、そのファイルへのアクセスは考えていなかったです。確かにそれもありますね」などと答えてくれました。 

でこんなツイートしたんですが

この質問聞かれたら正直ほげほげふがふがって感じだったけどまあ・・・ソース全部読むのは・・・時間無いし・・・難しそうだし・・・でスルーしていました。ただPosgreSQL側の話題だったんですが、こんな分かりやすいツイートを拝見したので

自分でもMySQLシステムコールを取ってみました。ちなみにstraceによる調査方法はPercona先生も分かりやすく方法を書いてくれています。

www.percona.com

実行環境はAWS EC2上でMySQL Serverを起動 AMIはamzn2-ami-hvm-2.0.20210617.0-x86_64-gp2 Versionはmysql-community-server-8.0.26-1.el7.x86_64

結果から言うと

[ec2-user@hogehoge ~]$ cat /tmp/strace.out | egrep "open"
5701  openat(AT_FDCWD, "/var/log/mysqld.log", O_WRONLY|O_CREAT|O_APPEND, 0666) = 37
5701  openat(AT_FDCWD, "/var/log/mysqld.log", O_WRONLY|O_CREAT|O_APPEND, 0666) = 37
5701  open("./", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 37
5701  openat(AT_FDCWD, "./binlog.index", O_RDWR|O_CREAT, 0640) = 4
5701  openat(AT_FDCWD, "./binlog.~rec~", O_RDWR|O_CREAT, 0640) = 37
5701  openat(AT_FDCWD, "./binlog.~rec~", O_RDWR|O_CREAT, 0640) = 37
5701  openat(AT_FDCWD, "./binlog.000003", O_WRONLY|O_CREAT, 0640) = 38
5701  openat(AT_FDCWD, "./binlog.index_crash_safe", O_RDWR|O_CREAT, 0640) = 39
5701  openat(AT_FDCWD, "./binlog.index", O_RDWR|O_CREAT, 0640) = 4
5701  openat(AT_FDCWD, "./test/oranie.ibd", O_RDWR|O_CREAT|O_EXCL, 0640) = 37
5665  openat(AT_FDCWD, "./test/oranie.ibd", O_RDWR) = 37
[ec2-user@hogehoge ~]$ 

という結果でした。なのでログ書いてbinlog書いてすべてが終わったらibdファイルを書いているという動きのようでした。それぞれのファイルの細かい説明、特にbinlog周りは後ほど調べます・・・。.~rec~って知らなかった。 -> 昨日データ操作なのにmysqld.logに書いているのとりあえずなんかおかしいと思いながらそのまま書いていたけど、模範解答貰えたので追記。

AWS : Online Ask an ExpertにExpert Dayというのを企画したのでみんな相談に来てください

皆様はAWS LoftのAsk an Expertというのをご存知でしょうか?

AWS Loft Tokyo – Ask an Expert コーナーがオンラインで復活! | Amazon Web Services ブログ

AWS LoftではAsk an ExpertというカウンターがありAWS Loftに実際にお越しいただいて開発をする方が気軽にAWSメンバーに相談出来る窓口がありました。COVID-19の影響でAWS Loft 目黒が現在クローズしており、AWSに相談したい!という要望を受けオンラインでも提供をしています。

で、今はどんな質問でもその日に対応するメンバーがやります!という状況なのですが、サービスがとても増えたこともありメンバー内でも得手不得手が正直あると考えています。僕も自分が所属しているチームで専門にしているDynamoDBに関する質問へのサポートは自信を持っているのですが、他のサービスでは相談した方に満足が行く回答が出来るかと言われるとちょっとむずかしいかもしれない、だったらむしろこの日にサービスを特化して相談出来る日を作ろう!と企画した日になります。

という訳で同じ様な社内のメンバーを募り2021/2/19 金曜日だけはContainer/Database/Analyticsサービスに特化したExpert枠が追加されました。DBだけに限らずなので例えば

  • 想定しているワークロードでは、どのコンテナサービスと組み合わせてどのデータベースが良いか悩んでいる

  • データベースに入れたデータをどういう分析フローに載せれば良いのか悩んでいる

など、コンテナ x DB x Analyticsが組み合わさった相談ももちろん可能です。

注意点としては、専門以外の領域は対応が完全にベストエフォートになるので、General枠の方に相談を予約して頂いた方がおそらく満足出来ると思います。それぞれの枠で対応可能なサービスが記載されているので確認宜しくお願い致します。

予約フローは

Online Ask an Expert – Special Expert Day のご案内 | Amazon Web Services ブログ

で詳細が乗っていますがこちらでも紹介しますね。

awsloft.tokyo

このサイトの「オンライン相談」というタブからまず予約する画面 https://awsloft.tokyo/reserve

へ遷移してください。まだ登録がない場合、事前にAWS account IDを含めた情報の登録が必要になります。予約枠の画面が表示されたら

f:id:oranie:20210212200929p:plain
予約画面
赤のExpert Dayの枠を選択してください。時間帯によっては現在対応出来るExpertが違うため、ご自身の相談サービスが記載されている枠で予約をお願いします。また、予約をする際に相談内容を書いて貰うのですが、そこで記載がなかったサービスについては当日担当者が相談に参加しないので、例えば

こういうワークロードでDynamoDBとGlueとECSについて相談したい!という具体的なサービス名や、RDBMSとNoSQLで悩んでいるなどのリクエストを必ず記載お願いします!!

もし登録をする際に何か分からない、おかしいみたいなことがあれば #AWSLoft のハッシュタグをつけてTwitterにつぶやいて貰えれば、内容などによりますがベストエフォートでスタッフがサポート出来るときはお手伝いするかもです。

以上、皆様是非相談に来てください!好評なら第二回、第三回とやっていきたいなと考えています。

「秘伝のタレ」とはなんなのか?というコバンザメエントリ。

素晴らしい内容のエントリですね。

https://kazeburo.hatenablog.com/entry/2020/12/17/164857

ここで出てくる「秘伝のタレ」とはなんなのか?久しぶりにmy.cnf見て意味忘れていたので自分の復習というコバンザメエントリです。 それぞれの内容はオフィシャルドキュメントを確認するのが一番正確です。

innodb_doublewrite = 0 https://dev.mysql.com/doc/refman/8.0/en/innodb-parameters.html#sysvar_innodb_doublewrite https://dev.mysql.com/doc/refman/8.0/en/innodb-doublewrite-buffer.html

innodb_flush_log_at_trx_commit = 2 https://dev.mysql.com/doc/refman/8.0/en/innodb-parameters.html#sysvar_innodb_flush_log_at_trx_commit

上記2つは http://nippondanji.blogspot.com/2010/03/innodb.html にも解説があるのでそちらで確認がベスト。要は多少DIsk障害時の信頼性を犠牲にするけどより効率的にDisk I/Oを使うための設定か。

innodb_flush_method = O_DIRECT_NO_FSYNC https://dev.mysql.com/doc/refman/8.0/en/innodb-parameters.html#sysvar_innodb_flush_method

ここまでの3つでDisk I/Oを少しでも効率的にするのが目的だと思われる。

innodb_adaptive_hash_index = 0 https://dev.mysql.com/doc/refman/8.0/en/innodb-parameters.html#sysvar_innodb_adaptive_hash_index https://dev.mysql.com/doc/refman/5.6/ja/innodb-adaptive-hash.html https://dev.mysql.com/doc/refman/5.6/ja/index-btree-hash.html

今回のワークロードに向かないIndex処理をしない

という形がコトコト煮込まれた内容のようです。なので実運用上は問題無いケースもあれば、ある要件によっては設定するとウッという可能性もあるので無条件にスループットを求めてとにかくみんな設定すれば良いのかはエントリ主のkazeburoさんやyoku0825さんとかが解説してくれる気がします。そもそももう数年前にされている可能性高いけど、

「伝わる短い英語 Plain English」という本がとても素晴らしかった

2020/6/17 追記 そもそも僕の文章が分かりづらい、という至極まっとうなコメントがあったので若干修正。本を読見直してもっと分かりやすい文章書けるようにならないと。

今日こんなツイートしたら

結構色んな人がLikeしてくれたので改めてブログに。

自分は英語全然出来ないので仕事でもコンプレックス満載なんだけど、さすがにまずいと思ってちょっとは勉強しているんですね。どうしても長文とかがスッと頭に入ってこなくて、仕事のドキュメントやメールを見ても何度か読み直さないと理解出来ないし、同じような文章をメールで書けないので本当に駄目だなぁと思っていました。 ただ、英語出来ないことには変わらないけど、別に仕事などで必要じゃなければ難解な表現や文学的な表現とかはむしろする必要が無くてシンプルな英文を作れれば良い、むしろその方が有益というのをこの本で学べたことはかなり肩の力を抜ける気がしました。下手すると「俺が理解出来ないのはこの文章が難解な構造だからだ」くらいからスタート出来るので時間掛かってもまあ良いかとかなり精神的に気が楽になりました。

で、ちゃんと本の紹介をすると「伝わる短い英語―アメリカ、イギリス、カナダ、オーストラリア 政府公認 新しい世界基準Plain English」というタイトルどおりPlain Englishというフォーマットについての解説です。

jpelc.org

序盤少し引用すると

そして、現在のネットワーク社会による情報過多の環境下で私たちはスピーディーに情報処理を行い、コミュニケーションすることが強いられています。 現在の欧米のビジネス文章の1センテンスの推奨ワード数は20ワード以下です。 情報に修飾を施すことなく、ダイレクトで簡潔、効果的表現を駆使して、たった20ワード内で、情報を伝達するための工夫がされています。 そうした表現の効果と効率をルールとしてまとめたものがPlain Englishガイドラインです。 現在 Plain Englishで書かれる代表的なものが、米国大統領の就任演説であり、ウォール・ストリート・ジャーナル、投資家向けIR資料です。

というとても体系だったルールであり、

米国では、政府からの通達される文章に対し、平易な言語のムーヴメントが1970年代に始まり、1978年に当時の大統領であるジミーカーター氏が政府規制を「費用対効果」(cost-effective)と「わかりやすさ」を推進することで、それまでの問い合わせや訴訟における賠償コストを削減し、一人でも多くの国民が規制を遵守し、そのパフォーマンスの向上を目論み大統領令を発令しました。 現在では、多くの機関が平易な言語を義務化する長期的な政策をとっており、1933年証券法に基づいて、証券取引委員会(SEC)は、1998年にその規則に採用し、法的義務化がされました。そして、現在では、新聞、雑誌など一般的に使用されています。

となっており広く読まれるドキュメントを書く際には法的義務になっているルールのようです。

そのため本の中でも二重否定のような文章は単純な肯定文で書きなさいというような具体的な解説であったり、トランプ大統領のスピーチは小学4年生でも理解出来るレベルでわかりやすくなっている事がスピーチの効果を高めているなどの解説が書かれておりとても分かりやすく学べる内容になっていました。

日本語でもやりがちですが冗長であったり分かりづらく、難解な単語をとにかく多く出すことで自分の文章が良い文章のように見せようとする事を「多くの人が読む時に読みやすいかどうか」という観点で見直せるのは英語以外でも役立つ視点でした。

という訳で、簡単な書評ですが是非英語や分かりやすい文章を書くことを同時に学べるのでとてもお得な本だと思います。

目黒駅近くのテイクアウトやってたお店のメニュー写真

なんか真面目なエントリには程遠いけどせっかくなのでメモがてら。

5/7追加分

よし鳥は何度か行った事ある。焼き鳥屋で酒呑みたい。

f:id:oranie:20200509103715j:image
f:id:oranie:20200509103719j:image

5/6追加分

みんな大好きミート矢澤もテイクアウトやってる

ミート矢澤 東京 五反田本店

f:id:oranie:20200506143939j:image
f:id:oranie:20200506143936j:image

隣のあげ福も

とんかつ あげ福/index
f:id:oranie:20200506143943j:image

あげ福はほんと美味くて大好きなトンカツ屋。食いたくなって来た。

------

f:id:oranie:20200425224424j:image

sibafu
050-5304-6117
https://retty.me/area/PRE13/ARE13/SUB704/100000757098/

雅叙園近くで前のオフィスから近くだったのでチョロチョロ行ってた。少しエスニック風なアレンジしてる物が多いけど美味しい。

 

f:id:oranie:20200425224805j:image

http://www.bistro-jill.com/shop/shinatora.html

 

f:id:oranie:20200425225012j:image

http://www.bistro-jill.com/shop/

 

二店舗は同じグループでよく呑みに行ってた。ご飯が美味しい上にテイクアウトだと20%オフという凄まじくお得。 肉料理が美味しくご飯としても美味しいけど、食べるとお酒呑みたくなる。

 

f:id:oranie:20200425225138j:image
f:id:oranie:20200425225129j:image
f:id:oranie:20200425225142j:image
f:id:oranie:20200425225135j:image

 

この辺は普段行った事ないけど、この機会にテイクアウトしてみようかなと思ってとりあえずメニューだけ撮影。

 

 

 

iPhone11Proで使うeSIMはairaloが快適だった

海外旅行などでモバイル機器の通信をどうするかは以前こんな感じの記事を書いた。

oranie.hatenablog.com

そして昨年自分の不注意でiPhone7を微妙に壊してしまい、せっかくなのでiPhone11Proを買った。単純に容量がとにかくデカイのが欲しかったがカメラ性能が最高で本当に買ってよかった。子供も本当に可愛く撮れるし夜景とかも三脚無しでテキトーにやってもこんなに綺麗に撮影できるのかと感動した。

そしてiPhone11になったのでeSIMが使えるようなった事でまだ自分が実際に海外は行っていないが色々調べた結果airaloが良さそうだった。

www.airalo.com

そしてたまたま1月外出が多くて今使っているキャリアの帯域を使い切ってしまったので、検証がてら日本のSIMを買ってみた。感想としては本当に楽ちんでアプリポチポチしていたら慣れたら10分くらいでSIMが使えるようになる。またGB辺りの単価も安い気がする。

ただし通信量がunlimitedと書いているプランも実際はこんな感じで条件があるので買う前に一度確認した方が良い。

Twitterでつぶやいてから興味を持ってくれた人が実際に海外で試してくれたようだが、何も問題無く使えていたので多分日本だから簡単だった、みたいなのはなさそう。USだとt-mobile回線が使えるみたい。

唯一の問題は簡単設定用にQRコードが発行されるんだけど、これ設定するiPhoneのモバイル設定の追加画面のカメラでどうやって読み取らせるの・・・? スクショを一度どこかに送ってそれを読み込み・・・?誰か教えて欲しい。手動設定の情報もちゃんと表示されるしコピペも出来るから問題無いんだけど。

とりあえず今後の海外旅行などはeSIMで全て対応することで日本で使っているSIMを交換した後にちゃんとしまうとか、もし交換時にうっかりポロッと無くしたら帰国時どうしようとかの不安から解消されるのと値段も非常に安いので使っていこうと思う。

NatureRemoの温度、湿度、照度をAWSでグラフ化する

いろんな人がいろんなもので既に可視化するのをやっている大人気な題材ですが、僕も試しにやってみました。 とりあえずiPhoneでこんな感じで見える。

https://github.com/oranie/natureremo-create-graph/raw/master/NatureRemoGraph.png

実際のコードはこれ。

github.com

全体のアーキテクチャ図は https://github.com/oranie/natureremo-create-graph/blob/master/architecture.png https://github.com/oranie/natureremo-create-graph/raw/master/architecture.png

多少自分の仕事の検証も兼ねているため少し冗長な構成になっているが解説すると

  • Lambdaがスケジュール実行されNatureRemo APIを叩いて情報を取得
  • 取得した情報をDynamoDBに保存
  • 保存した情報をGlueで定期的にS3にparquet変換を行ってExport
  • Exportされた情報を元にAthenaでクエリによる集計が出来るようにtableを作成
  • 集計クエリを元にQuickSightで可視化

となる。QuickSightはiPhoneアプリもあるので、これで自宅の状況がグラフ化されモバイルアプリで自分や家族だけ見ることが出来るようになった。次回のブログではgithubに上がっていない部分の手順やもう少し細かい解説をしたいと思っている。また情報が整備出来たらaws-samplesでももっとわかりやすいハンズオンとして公開をしたいと考えているのでもし実際に試してみたい人は少しお待ち下さい。

他の事例同様サーバレス構成で完結しているので運用管理などはかなり楽が出来る事と、ある程度のコンポーネントが既にあることでここから別のトリガー処理(例えば湿度が一定以下ならLINE通知をするとか)なども比較的書きやすかったりQuickSightで予測をさせるなども出来るため色々個人の事情に応じてカスタマイズなどもしやすいと思う。

もちろん、Lamba -> S3 -> QuickSightというような流れで最小限の処理に書き換える事でよりコンパクトなアーキテクチャに出来るのでその辺も色々試しやすいと思う。