00:02
はい、みなさんはじめまして。ひとなみクラブはEC事業部の2人が技術や社内の出来事などについて話す
gmo pepawの社内ポッドキャストです。 今回は初回ということで収録の練習を兼ねて2人の自己紹介とちょっとした
トピックとか最近気になっていることについて10分くらい話してみようと思ってます。 それでは最初に自己紹介をしようと思います。じゃあまずはたかぴーどうぞ。
はい、なんか緊張しますね。 よろしくお願いします。EC事業部の高橋と申します。
たかぴーと社内では呼ばれております。 エンジニアリングリードをやっておりまして、主に業務ではセキュリティ施策の進行だったりとか計画だったりとかを
やって、あとはですね、レガシー基盤の 改善などを行っております。本日はよろしくお願いします。
はい、じゃあ私最初に ちょっと話したんですけれども、EC事業部でシニアエンジニアリングリードをやってます。
同じく高橋です。あだ名はくんさんとかって呼ばれています。 もともとはRubyのサーバーサイドエンジニアとしてペパボン入社して今はEC事業部でいろいろやっております。
はい、じゃあ今日は皆さんよろしくお願いします。 よろしくお願いします。
はい、じゃあ収録慣れてない感じが出てますけれども。 もう早速言い間違えましたからね。レガシー基盤ってなんだろうね。
はい。 じゃあ今日は練習も兼ねてっていうことなんで、ちょっと軽く話しながら、こんな感じで収録したらいいかなっていうのが分かってきたらいいかなと思ってます。
はい、ということで一応今日は1人1個ぐらいずつトピックを持ってきたので、それについてざっと1つ5分から5分ぐらいですかね、話してどんどんいければなと思ってます。
はい、じゃあどっちからいきましょうか。
じゃあ私からでも。 いいですね、はい。
私から始めていきたいと思うんですけども。 先ほど各1つずつって言ってたんですけど、私は実は2つ用意してどっちにしようかなって思ってるんですけど。
そうですね、じゃあちょっとこっちにしようかなと思っていて。 最近ですね、実は執筆活動でちょっとバタバタしていて、すごく忙しい思いをしていたんですけど、何をやってたかっていうと、技術評論者のソフトウェアデザインっていう商業誌があると思うんですけども、
それの記事を特集2を書いてみました。
03:03
どんな内容なんですか?
ごめんなさい、どうぞ。
5月に出る予定で、内容としてはテパ号で年1回行っているインシデント対応訓練を題材に書いていったという感じでございます。
インシデント対応訓練のどんな切り口で書いたんですか?
そうですね、元々ちょっと経緯から話すと、技法さんからフリーさんにそのインシデント対応訓練の特集をやりたいよってことで声がかかって、
フリーさんは元々大規模な会社全体のインシデント対応訓練をやっていて、そのフリーさんからテパ号はどうですかっていうことでお声がかかったっていう感じの経緯になってますね。
ミンネの方でミンドリっていう障害訓練をフリーさんが見て、それを見てテパ号にお声がけいただいたんですけど、どういう切り分けでやっていくかっていうと、
フリーさんは会社全体の大規模な訓練っていう、インシデント対応訓練っていう特集を、
我々のテパ号は事業部ごと、サービスごとの割と小さめのインシデント対応訓練をどうやってるかみたいなところのお話をしてるっていう、そういった分け方で書いておりますね。
なるほど。なので、2社で書いたっていう感じなんですね。
そうですね、はい。
そういうのも結構雑誌とか本とかならではで、他の会社さんと一緒に記事を書くとかも面白いですよね。
そうですね。なかなか他社でどうやってやってるんだろうみたいなところ。
もちろん記事では見たりは、ブログとかで見たりするんですけども、実際書いてる様子だったりとかを経緯とかを見る機会がないので、そういったところは新鮮でしたね。
確かにいいですね。
ちなみに何か面白いエピソードとか苦労したところとか何かありますか。
そうです。面白い話はあんまりないかな。
大変だっただけって感じですか。
もうとにかく、今回10ページを書く、10ページ10ページずつぐらいかなっていう感じで分けて書いてるんですけども、
文字数にすると約1万2000字ぐらいなんですけども、
10ページ障害訓練何書こうみたいなところからちょっと構成だったりっていうところですね。
これをすごく悩んだりとか、あとはそもそも日本語を書くのがなかなか慣れてないというところがあって、
06:01
個人ブログとか結構カジュアルめに書いてしまうところがあったりとかするんですけど、
割と全国に出るような商業紙なのでちゃんと書かなきゃなということで、
日本語をちょっと苦戦しながら頑張っておりました感じですかね。
いいですね。商業紙出るのなかなかないことですし、
ちょっと前に柴田さんがテックブログとかにも書いてました。
機械を逃さないようにするっていうところが上手く回ったんだなっていうのがすごくいいですね。
聞いてる方に宣伝とかありますか。
そうですね、宣伝。
まだ商業紙は出版されてはいないんですけど、これから印刷してっていう工程なんですけど、
きっと出たらすごく嬉しいなっていう気持ちと、
自分を社外にアウトプットするっていうか、アピールする機会っていうのもあるんで、
そういうのを、ペパボのアウトプットもそうなんですけど、
自分の中のアウトプットとしては多分最大級のものなのかなとは思ってて、
1個それをやり遂げると他のアウトプットも自信がついてくるかなと思うので、
ぜひ機会があればやってみてくださいというか、
なるほど。
チャレンジしてみてくださいっていう感じですね。
ありがとうございます。
じゃあ、5月号、来月出版ってことですか?
そうですね。
来月出版なのかな?
締め切り日を意識しすぎて、その辺の日があまりチェックできてないんですが、
おそらくそうなるかなとは思ってます。
じゃあ、また出版した際には広くお知らせとかがあると思うので、
皆さんよかったら買っていただけたり、感想とかね。
社内であればスラックとかでも、社外のブログとかツイッターでも何でもいいので書いていただけたらなと思いますね。
じゃあ、1つ目のトピックはそれぐらいで終わりましょうか。
じゃあ、もう1つってことで私が持ってきたトピックは、
どうしようかな、技術的な話かそうじゃないのかで迷ったんですけど、
じゃあちょっと技術の話を持ってきたので、それにしようかなと思います。
私が今週ちょっとマージしたプルリク1つ紹介したいなと思って持ってきました。
何をしたかっていうと、
目的としてはCIを2,3分ぐらい早くしたっていうのが多分やったことの
09:06
サマリになるかなと思うんですけど、
これちょっと面白くはないですけど、工夫したことがあるんでそれを紹介したいなと思いました。
これ何したかっていうと、ちなみにたかぴーこれ知ってますか?
なんかプルリクは見かけたんですが、ちょっとまだ中身はこれから見ていくっていう感じですね。
そんなにディフはすごい大きいんですけど、やったことはそんなに大したことじゃないというか、少ないんですけど、
カラミーショップのCIでは、カラミーショップに限らずだと思うんですけど、
マスターデータというか初期データをセットアップするみたいなのってだいたいどこでもやられるじゃないですか。
これがカラミーのやつめちゃくちゃ遅いっていうことに年末ぐらいにちょっと気づいて、
なんとかしたいなってちょっと思ったんですよね。
何が遅いんだろうって見ていくと、初期データの中でいくつかめちゃくちゃでかいデータみたいなのがあって、
例えばカラミーだと、レビューの中に実は郵便番号と住所のペアみたいなやつとか、
都道府県のコードと都道府県の一覧とか、そういう住所関連のデータをいくつか持ってるっぽいんですね。
これが郵便番号の数だけデータがあったりとかしていて、かなりでかいデータを入れようとしてるんだけど、
どうもそれがちょっと待ってるねっていうのが見てたらわかったんで、
これは早くならんのかなと思って色々調べたりしてたっていうのが最初です。
結論から言うとどういうことをしたかっていうと、
ただいっぱいインサート文が並んでたんで、それをバルクインサートにインサート文一つにして、
その中でたくさんデータを入れるようにするっていうのをそれぞれのテーブル単位でやったっていうのが今回やったことなんですね。
これ実は年始ぐらいから仕込みをしてて進めてたんですけど、
なんでそんなに時間がかかってるかっていうと、
今私たち絡みだとMySQLっていうデータベース使ってるんですけど、
MySQLに限らずですけど、受け入れられるSQLの長さみたいなのって実は設定がそれぞれあるんですよね。
なるほど、それは知らなかった。
そうなんですよ。MySQLだとMaxAllowedBucketっていうので定められてるんですけど、
どれぐらい長いSQLが受け入れられるかって、
それぞれRDBMSで設定があって、
それを超えるものを投げようとするとバツッと切られちゃうみたいなのがあるんですよ。
全部の住所データを入れるっていうのはさすがにテキストファイルでも数メガぐらいあるやつで、
12:04
でかいんですよね。
これが最初弾かれちゃって困ったなってなってたので、
これの設定を本番からCIで使うDBのコンテナまで全部揃えるっていうのを先にやろうとしていて、
これをちょっと先にやったっていうのが実はあります。
なるほど、本番に合わせたっていうこと。
実は本番がデフォルト値になってて、それがそもそも足りてなかったんですよね。
それに合わせて他も全部デフォルト値になってたんで、
全体では合ってたんですけど、本番をまずそれがもし流れても大丈夫なように合わせてでかくしようと思って、
まずでかくしてからそれぞれの使ってるイメージの設定ファイルとかをその本番を増やしたのに合わせて、
合わせていくみたいなことを最初にやってたって感じです。
なるほど、ISQLコンフみたいな。
そうそう。
なるほど。
なので、今はRDS使ってるので、RDSのパラメータグループかな、
パラメータグループっていうので設定できるので、それをまず設定して、
それと同じISQLコンフになるようにCIとかで使ってるイメージを更新するみたいなのを順番にちょっとやってたって感じですね。
なるほど。
それで無事、超巨大なSQLが受け入れられるようになったので、最後にそれをマージしてもらって、
今のCIはちょっと早くなった、マスターデータのロードみたいなので回り始めてるっていう状態です。
なるほど。CIで2,3分ってかなりデカいですよね。
いやー、それそうなんですよね。結構あったなと思って。
そうですよね。
一応手元のベンチマークでも同じぐらいは早くなってたので、
CIでも同じぐらいになるといいなと思ってやったんですけど、期待通りっていう感じでしたね。
すごい。
これはちょっとやるときに最後ちょっと不安だったのが、バルクインサートにしたので、
例えばなんですけど、4つマスターデータありますっていうときに、
例えば仮に2だけはぬけんみたいになってる状態でやるとどうなるんだろうっていうのがあったんですね。
それってどういう状況で起きるかっていうと、
例えば新しいマスターデータを追加するみたいなときに、また同じようにインサートも増やしていくといつかまた遅くなっちゃうので、
バルクインサートでやりたいんですよね。
重複したデータを入れないっていうのがSQL文には一応あって、
インサートイグノアっていうのがあるんですけど、
これをやると、あれば何もしないし、なければインサートするっていう挙動ができて、
これが実はバルクインサートでも同じようにうまく動いてくれるっていうのを最後検証してて、
15:01
それで大丈夫そうだったんで、新しいデータ追加するときもバリューのどこだけ並べてくれたら足りない分だけ入るから便利だねってなって、
これなら大丈夫かなというので最後マージしたっていう感じでした。
もうちょっとサクッと終わればよかったのと、
試合2分早くなっても意外とテストの方がやっぱり時間かかるので、
早くはなったんだけど、もうちょっと効いてくるのは後かなっていうのは思いますね。
そうですね、テストの方が結構最近だとアドミンのテストが膨れてきて、
ただ15分とか以上かかり始めているみたいなところがあるので、
ちょっと並行してやっていきたいところはあるんですけど、
そっちが改善してくるとまた試合で2,3分早くしたのがまた効果が出てくるのかなと思うので、
すごく良いかなというか良い話だなと思いました。
ありがとうございます。
じゃあそれぞれ1トピックずつちょっと話したので、
これそろそろ締めにいこうかなと思います。
大体今ので15分から16分くらいなので、大体予定通りかなという感じかなと思います。
ちょうどいい時間になってきたのでそろそろ締めにいくんですが、
ひとなみクラブはこれからも週1か2週間に1回ぐらい更新できたらなと思ってますので、
更新したらまたお知らせすると思うのでよろしくお願いします。
このポッドキャストへのご意見ご感想2人へのお便り、
興味があるのでウォッチしたいという方は、
運営も兼ねているペパボーのスラックの中にチャンネルがありますので、
もしよかったら来ていただけたらなと思います。
チャンネル名はH173、173でひとなみっていうのと語呂合わせをしてます。
それでは第0回そろそろ終わろうと思います。
ありがとうございました。
ありがとうございました。
バイバイ。
