YT YouTube2Text

YouTube2Text → Transcripts → layerx.go #1 〜最適化・効率化〜

layerx.go #1 〜最適化・効率化〜 — Transcript

by LayerX 公式 · 1,284 words · 1,284 segments · language ja · Watch on YouTube

Open in transcriber Summarize with AI Download SRT/VTT

Full transcript

0:00はいえ皆さんお集まりいただきありがとう
0:03ございます7時になったのでレアX5始め
0:06ていきたいと思いますよろしくお願いし
0:11ますはいまず私の軽い自己紹介なんです
0:15けどえっとパミュと申しましてえっと今は
0:18axの暴落事業部というところで
0:20ソフトウェアエンジニアをやってい
0:23ますはいでまず最初に簡単に会社の紹介
0:27だけさして
0:28くださいはいLXは全ての経済活動を
0:32デジタル化するというミッションのもやっ
0:34ている会社ででいくつか事業をやっている
0:37んですけどと暴落事業とFinTech
0:39事業とailllm事業がありましてで
0:43今日登壇する弊社の3名は全員爆事業に
0:47所属してるエンジニアになってい
0:50ますはいでAX5についてなんですが
0:54えっと今回シープ1なんですが実はシープ
0:570がありまして2ヶ月前にやったんです
0:59けど
1:01なんでやり始めたのかっていう話を
1:02ちょっとするとaxの5言語の実践的な
1:06あの活用事例を共有するだけじゃなくて
1:09社会の方からの試験も積極的に取り入れる
1:12場としたいっていうのが1つあってであと
1:15LAXの構造針ベッドテクノロジーって
1:17いうやつと得っていうのがあるんですけど
1:20その観点からこのイベントを継続的に開催
1:22することで合言語のそのを広げていきたい
1:25という気持ちからこれが始めましたって
1:28いう前提がありますはいで毎回毎回って
1:32言って2回目しかやってないですけどあの
1:34シャープ1今回のテーマは5の最適化効率
1:38化っていうテーマになっていますでそう
1:41そうですねTwitterの方ハッシュ
1:42タグはえっとシプレX5えっと全部文字で
1:46えアスコも何もないレ5ですなので皆さん
1:51是非ついて
1:53くださいはい今日のタイムテーブルなん
1:56ですけどこんな感じになっていてえっと
1:59そうですねえ10分の発表でえ最初の3名
2:02が弊社からの登壇でですね
2:07で後半の宇さんと藤原さんがえっと今回
2:10ゲストゲストとして来てくださっています
2:13でえっと7時55分から8時までえっと
2:17アンケートを取って取ってその後1時間懇
2:21L会という形になっています
2:24はいでは早速なんですがレアx5シプ1
2:28始まりますということで最初の登壇者の
2:31大森さんお願いしてもいいですかね
2:37[音楽]
2:51[音楽]
3:01大丈夫ですかあはいそれではえっと1番目
3:07ですねPプロフで見つけたアウトオブ
3:09メモリの真相と題しまして発表させて
3:12いただきますよろしくお願いし
3:18ますまず自己紹介っとレアXの暴落事業部
3:23で法人のクレジットカードですね爆
3:25ビジネスカードというところでエンジニア
3:27をえと6月までしておりますして今はAI
3:31UXっていうところでAIの体験を良く
3:33するためにえっと活動していますXは
3:36onsdアバーというIDでやってるので
3:39よろしければフォローしてくださいえっと
3:41えっとレXでは1つの機能を1人の
3:45エンジニアがバックエンドからフロント
3:46エンドまで一期通過して開発することが
3:48多くえっと自分もGOとタイプスクリプト
3:51でプロダクト開発をやっております
3:53よろしくお願いし
3:55ます今日話すことについてですねえっと
3:58プロファイリングツールを使って
4:00アプリケーションのアウトオブメモリの
4:02原因を調査する方法をご紹介しますこのお
4:05話はえっとブログの記事が元になっており
4:08ましてレアXのエンジニアリングブログ
4:11から見ることができますのでよろしければ
4:13そちらもご覧
4:17くださいはいまず背景ですねと暴落
4:21ビジネスカードはgqlgenenという
4:23ライブラリーを使ってグラフQLの
4:25サーバーを実装しておりますその中の1つ
4:28の機能としてユーザーからファイルを
4:30受け取ってS3にアップロードする機能が
4:33ありますでえっとタスクについてえっと
4:37ファイルサイズの上限が当時
4:4950mbar
4:50えっとスペッに出しているようなMAX
4:53アップロードサイズだったりMAXメモリ
4:56を変えてあげるとその上限を変えることが
4:59できます
5:01でさっきのように80MBにアップロード
5:04して手元で動作確認して80mJAの
5:07ファイルもアップロードできたのでマジし
5:09てみましたで開発環境の様子を見ていた
5:13ところたまに500のレスポンスを返して
5:15いるっていうことを見つけましたで実際に
5:18開発環境に向かって80mJAのファイル
5:21をアップロードすると500が返って
5:23くるってこを確認しましてコンテナのログ
5:26を見てみるとアオブメモリで死んでいたと
5:28いうことが分かりますこれが実際のAWS
5:31のコンソールのログスクリーンショットな
5:34んですけどこんな感じで死んでたよって形
5:36ですねでえっとアウトメモリの原因をP
5:41proofを使って調査することにしまし
5:44たPproofについて簡単に説明させて
5:47いただきますPプロフとはパフォーマンス
5:49分析や最適化に利用される
5:51プロファイリングツールです分析できる
5:54ものとしてはCPUの使用状況だったり
5:56メモリの使用状況ゴルチンの動作状況とか
5:59を分析することができます利用方法として
6:03は大きく2つありましてランタイムスピー
6:06プロフパッケージを使ってプロファイル
6:08データをファイルに出力する方法とネット
6:11スラhttpPプロフパッケージを使って
6:14http経由でプロファイルデータを取得
6:16できるようにするという方法の2つがあり
6:18ますえっと今回みたいなアプリケーション
6:21サーバーで分析をする場合は後者を使う
6:24ことが多いかなと思いますで取得した
6:27プロファイルデータはGOPProという
6:29コマンドを使って解析だったり貸し化など
6:32ができますちなみにえっとプロファイル
6:34データはプロトファフのこんな感じの
6:36フォーマットで保存することができて
6:38えっと実際に公開もされてるのでどんな
6:41感じになってるのかなっていうのは見る
6:42ことができ
6:44ますはいでまず1つ目ですねどこでえっと
6:48メモリが使われてアウトメモリになって
6:50いるのかっていうのを調査しましたで
6:52さっき言ったようにネトhtppプロフを
6:56使ってプロファイリングをします使い方と
6:58してはこんな感じでネットスラhttp
7:01プロフをまずブランクインポートした後に
7:03メイン関数の1番最初
7:05でえっとゴルチを使って6060番を
7:10リスンするみたいな書き方をしてあげます
7:12あとは既存のアプリケーションの処理を
7:14そのまま書くだけで大丈夫ですこの状態で
7:17実行するとプロファイリングが始まり
7:21ますで今回アウトメモリの原因を調べると
7:25いうところでメモリの使用量を見てみます
7:27えっとメモリ多使使っている関数から見
7:30たいというところでGOツルPプフ配分
7:33トップというオプコマンオプションを使っ
7:35て
7:38えっとプロファイリングの分析を行って
7:41おりますえっと青いとこま画面の真ん中の
7:44方ですね青いとこリードールがえっと
7:46154MB使っているということがここ
7:49から分かりまし
7:51たじゃあえっとどこでアオリドールを使っ
7:54ているのかっていうのをソースコードを
7:56ガっと見てみると先ほど言ったような
7:59えっとユーザーからファイルを受け取って
8:013にアップロードするっていう処理のま
8:04まんまなんですけどそこで使われてい
8:06るってことが分かりましたえっとデフ
8:09みたいな感じでえっと赤く出しているん
8:10ですけどえっとリドルを使って
8:13アップロードされたファイルを
8:15全部メモリに載せてからAWSputS3
8:20オブジェクトっていう関数でAWSに上げ
8:22ているって処理ですねでこれファイルに
8:25対して何か処理を行っているわけでは
8:27なかったのでAWSsdk5のS3
8:30マネージャーを使ってオンメモリで処理
8:32できるように修正をしましたこうすること
8:35でアリドールしなくなったのでえっと
8:38メモリを使うことはなくなったじゃないか
8:40なと思っていましたでこの状態でもう1度
8:44実行してプロファイリングを取ってみ
8:48ますで再度計測してみると以前アオリ
8:52ドールはいるんですよね75メカ使って
8:55るってことが分かります
8:58とこれじゃ誰が呼んでるんでしょうって
9:01いうところでこの状態でソースコードに
9:03リドAllは存在しないっていうとこは
9:06分かってますでてことは多分どっかの
9:08ライブラリーが呼んでいるんだろうとこと
9:10は分かるんですけどそれの調査するために
9:13資格的に呼び出しを追うためにpofの配
9:16PNGオプションを使ってみましたこれを
9:18使うと関数の呼び出し順を示した図が出力
9:21され
9:23ますちょっと見づらい図にはなるんです
9:25けど左がこうやってどんな順番で関数が
9:29呼ばれてるかっていう図になりますえっと
9:33矢印ついてるとこですね大きくしてみたの
9:35がえっと右にあるんですけどサブhttp
9:38からマルチフフDoが呼ばれてそん中でi
9:42reallが呼ばれているといった形に
9:44なり
9:48ますで結局アオリドールを呼んでいたのは
9:51gqlgenenのマルチ
9:52プラットフォームDoという関数でした
9:55この関数はえっと内部でMaxメモリーと
9:57ファイルサイズを比較して動が変わるよう
10:00になっていましたファイルサイズの方が
10:02大きい場合は一時ファイルを保存してそこ
10:04に保存作成してそこに保存しますで
10:07ファイルサイズの方がMAXメモリより
10:09小さい場合はIドルを利用してメモリに
10:12コピーするという形になっておりますで
10:15最初のタスクの対応の時に80mbbに
10:18受け付けで対応した時にMAXメモリも
10:2080mに対応変更したっていうのがま原因
10:23でこうなっているってことが分かりました
10:26でこれに対してECSのメモリが小さかっ
10:28たのがメモリの原因ということまで分かっ
10:31たのでメモリを増やす対応したという形に
10:33なり
10:35ますえっと駆け足だったんですがここで
10:38終わりにということでアトメモリが起きた
10:40メモリを増やそうではなくてどこがメモリ
10:42を使っているのかっていうのをきちんと
10:44調査して対応することができたってのは
10:46良かったなと思いますまたえっと
10:48プロファイリングツールを使うことで根拠
10:50を持った改善ができましたでPプロフだけ
10:53じゃなくて調査後にGPプロフっていう
10:56ツールを教えてもらいましたこちらはP
10:58proofでは測定でないofCPU
11:00例えばインプットアウトプットとかですね
11:02の測定ができるツールになっています
11:05えっとなんでDBアクセスとか含めた
11:07パフォーマンスチューニングとかをする
11:09ことがあったらこういうのを試してみたい
11:11なと思いましたまたえっと利用している
11:14ライブラリーのコードを実際に読んでみる
11:16ことでどんな挙動をするのかの理解が
11:18深まったので一石2長だったなと思って
11:20おり
11:21ますとパ最後にですねレアXの開発につい
11:25て興味ある方是非ぜひお話させてください
11:28この後の今新会でもよろしくお願いします
11:31はいちょっと駆け足でしたが以上になり
11:33ますありがとうござい
11:35[拍手]
11:35[音楽]
11:39ますはい発表ありがとうございましたでは
11:43次
11:44はPGOの話山さんお願いし
11:49[音楽]
11:51ます
11:53ああよいしょ
12:01はいえじゃ次の発表始めていきますCIC
12:04CDにPGを組み込んだ話というテーマで
12:07お話させてもらいますよろしくお願いし
12:12ますでえっと最初に軽く自己紹介で岩松
12:16翔太と申しますえっとレアのエンジニアを
12:19やっておりましてバラックビジネスカー
12:21ドっていうあの法人向けのクレジット
12:24カードを開発してますでえっとま全も決済
12:27系だったのでま割と際決済したキャリアに
12:31なっておりますま合歴は3年ぐらいですね
12:34はいでえっとま事業紹介飛ばしてえ今日の
12:39トピックなんですけどまPGOっていう
12:41ものについて説明しますでその後に実際に
12:44導入してみる時のあのどうやって導入する
12:47かっていう話とま導入してどうなった
12:49かっていうところをお話していければと
12:50思いますでえっとまずPGOとはっていう
12:54ところでまプロファイルガリッ
12:56オプティマイゼーションの略なんですけど
12:57コンパイラ一言言とコンパイラ最適化手法
13:00の1つですでえっともうちょっと具体的に
13:03言うとビルド時にコンパイラにあのさっき
13:05の話にも出てたプロファイルですね
13:07プロファイルを与えることであの実際の
13:10ワークロードに即した最適化を行うことが
13:12できるっていう方法のことですま平たくエ
13:15ばパフォーマンスを向上できるビルド方法
13:17になってますでまこれだけだとよくわかん
13:20ないと思うのでえっと例を交えて説明する
13:23とコンパイラ最適化の1つにあの関数関数
13:27のインライン化インライン展開っていう
13:29っていうのがありますでまその名の通りな
13:31んですけど関数予備出しを関数本体に
13:33置き換えるとことでことのことを指してて
13:37えっとまサムっていう例えばa+bをする
13:40関数があってでメインメイン関数の中で
13:43サムを呼び出して1+2をしてるコードが
13:45あるとしますとでえっとこれがビルド時に
13:48インライン展開されるとどうなるかって言
13:50とこのサムの呼び出しの部分がこんな感じ
13:53でA+Bに置き変わりますっていうのがま
13:56シンプルなんですけどインライン展開の
13:58説明です
13:59でこれの何が嬉しいのっっていう話だと
14:02思うんですけど2つあってま1個が関数
14:04予備出しのオーバーヘッドがなくなるって
14:06ところですねで通常関数呼び出す時ってま
14:09大体なあの秒レベルのあのオーバーヘッド
14:12が発生するんですけどこれがあの関数
14:14呼び出しが不要になることでなくなるので
14:16パフォーマンス上がりますっていうのが1
14:18個目ででもう1つがあのさらなる
14:20コンパイラー最適化が可能になりますとで
14:23これちょっと詳細は割愛するんですけどま
14:25インライン展開された後のコードに対して
14:28他の最適化適用できるようになったりする
14:30のであのパフォーマンスが上がりますって
14:31いうメリットがありますでここだけ見ると
14:34じゃあ全部インライン展開すれば良いので
14:37はっていう感じなんですけどまただし
14:40デメリットもあってまイメージしやすいと
14:41は思うんですけどバイナリサイズが増加
14:43するとかまビルド時間が長くなるっていう
14:46デメリットがありますとでまなので通常の
14:49ビルドする時にはあのま事前に決められた
14:53ルールに乗っ取ってあ単純な関数のみイン
14:55ライン展開するように対象を制限してます
14:59でまとはいえま1分間に何百回何十何千回
15:04とか呼び出される関数だったらま多少の
15:06デメリットを許容してでもパフォーマンス
15:08向上させたいみたいなのがあると思うん
15:10ですけどまただそれをやろうにも
15:12コンパイラとしてはソースコードしか情報
15:14がないんでま実際のワークロードにおいて
15:17どの関数がどんだけ呼び出されるのか
15:19みたいなのが分からないわけですねただ
15:22ここでプロファイルを与えることでまその
15:24辺りの情報が手に入るので実際のワーク
15:27ロードを加味した最適化ができるように
15:28なるっていうのがPGOの仕組みですで
15:31えっとGOでPGOを使う方法としてはと
15:34まずバージョンで言うとGO1.21で
15:36正式リリースされてるのでまその1.21
15:39以上使っていただいてでまあの適用するの
15:42は結構簡単でメインパッケージに
15:45defor.PGOっていうファイル名で
15:47CPUプロファイルを配置すればまビルド
15:49時に勝手にコンパイラーがプロファイル
15:51読み込んでくれてPGOが適用されますで
15:54公式ドキュメント曰2から14の
15:56パフォーマンス向上が見込めるっていう
15:58ところでですでは実際にマラビジネス
16:02カードの一部のサーバーに導入してみたん
16:04ですけどまその時にまいくつか考えないと
16:06いけないことがあってえままずどのように
16:09プロファイルを収集するかっていうところ
16:11でとまPGOでいい結果を得るための一番
16:15大事なのは実際のワークロードに近い
16:18プロファイルを収集できるかどうかって
16:19いうのが加になってますとまなので基本的
16:21には本番環境のプロファイルを取得する
16:24ことが推奨されててであのさっきの発表で
16:27もあったようにネhttppプロフとか
16:30使えば取得できるんですけどま自前でや
16:32るってなるといくつか考えないといけない
16:34ことがあってまなんかどこのポートを開け
16:36てどこからリクエスト送るのかとかいつ
16:39取得するのかとかま取得時にたまたま極端
16:42にリクエスト少ない状態だったらどうする
16:45かみたいなところがあのま考えないといけ
16:47ないですとでこういう時は継続的プロ
16:50ファイラーっていうのを使うと結構便利で
16:52ま名前の通りなんですけど常時
16:54プロファイルを収集して定期的に管理用の
16:56バサーバーに送信してくれるサービスの
16:59ことで必要な時に2位のプロファイルを
17:01ダウンロードすることができるんであの
17:04さっき言ったような課題は解決されますと
17:07で有名どころだとデータドッとか
17:10GoogleCloudとかグラファなと
17:12かが出してるんですけどまレXとしては
17:14オブザーバビリティ周りはあの基本的に
17:16データドックに集約してるんで今回は
17:18データドックを使ってますでまこれデータ
17:21ドックの画面なんですけどこんな感じで
17:23プロファイルがバーって一覧で並ぶんでま
17:26よさのやつをピックしてダウンロードでき
17:28ますとでまこれ以外にもパフォーマンス
17:31解析に便利ななんかフレームグラフとか
17:34プロファイル同士比較したりとかそういう
17:36ビジュアライズも用されてるんでまPG
17:38PG関係なくまこれ単体でも結構便利です
17:40とでえま導入も簡単ですって話なんです
17:44けどまちょっとこれ飛ばしてえっとじゃ次
17:48にまどのようにビルドプロセスに組み込む
17:50かっていうところですでまPGOにおいて
17:53プロファイルは1回収集して終わりじゃ
17:55なくてま当然あの日々の開発でソース
17:58コードはどんどん変化してくので
18:00プロファイルもできればやっぱ毎回直近の
18:02ものを使いたいわけですただまビルドの度
18:06に毎回テペでプロファイルを画面から
18:08ダウンロードしてきてコミットするのは
18:10面倒なのでこれ自動化したいよねっていう
18:12話でえまデータドッグの場合はデータ
18:16doogPGOっていうツールが用意され
18:18てるのでこれ使うと便利ですまあの結構
18:22単純でプロファイルをダウンロードする
18:23cliツールなんですけどえと具体的には
18:26直近72時間でCPU量が大きい
18:29プロファイルを5個選んでマジして
18:31吐き出してくれるっていうツールですねな
18:34のでまなんかgitHUBアクションズと
18:36かで5ビルドやってるところの手前に
18:38DATAドPGOを実行するあの一業を
18:41入れとけばdefor.PGOが作成され
18:43てでビルドのタイミングであのPGOが
18:46適用されるっていうような感じになります
18:49でここまでで準備は終わったので実際に
18:51本番環境に導入してどうなったかっていう
18:53ところを見ていきますでこれが結構下がっ
18:57たんですけどまCPU使用率が平均
19:0013.5%下がってますでこのグラフは
19:04あの1週間前のCPU使用率との比較で
19:08比較の変化率を表してるグラフなんです
19:10けどPGを適用したしてから結構ガクっと
19:13下がってますとでこれはCPUですけど
19:15メモリもま同じ感じで下がってて大体
19:1999.5%ぐらい下がってますっていうの
19:22だけ見ると結構すごいなという印象なん
19:25ですがまもうちょっと見てみると
19:27パフォーマンス工場の大部分は
19:30プロファイラーの処理の部分でまつまり
19:32あのPGOのために入れたプロファイラー
19:34がPGOによって早くなるみたいなあ
19:38ちょっとマッチポンプ的な結果になっ
19:40ちゃってますとあとはいえあの
19:42プロファイラーは別にPGO専用ってわけ
19:44じゃなくてパフォーマンス分析には欠かせ
19:46ないツールなのでまパフォーマンス除した
19:48のはま嬉しいは嬉しいですとでま実際の
19:51エンドポイントに限定するとま大体5%
19:53ぐらいのパフォーマンス工場でま実際時間
19:57で言うと1分あたりのCPU使用時間が約
19:594mm秒短縮されたくらいの
20:01パフォーマンス工場でしたとなのでま
20:04決して劇的な改善ではないんですけどま
20:06導入の手軽さを考慮すると十分な結果かな
20:09と思いますしまパフォーマンスが結構
20:11シビアなアプリケーションとかだったらま
20:12こういった改善も結構嬉しいのかなと思い
20:15ますでまその他の留意点としてはあのPG
20:19の説明のところでも言ったんですけど
20:20バイナリサイズが増加するとかビルド時間
20:22が長くなるみたいなのはあるんですがまあ
20:25今回やった感じだとそんなに気にならない
20:27ぐらいの像でしたというところですはいで
20:31はまとめでまPGOによりソースコードを
20:34変更しなくても2から14PAぐらい
20:36パフォーマンス控除が見込めますよって
20:37いうのとまプロファイルの収集は継続的
20:40プロファイラー導入すると結構便利ですっ
20:42ていうのとまcicdに組み込む場合はま
20:45データドックの場合はデータドックPGを
20:46使うと簡単に組み込めますよっていうお話
20:49でしたはいえ発表以上になりますご清聴
20:52ありがとうございました
20:54[拍手]
20:59はい発表ありがとうございましたなんか
21:01面白いおちでしたけどプロファイラーは
21:04あった方がいいですからねプロファイル
21:06ははいじゃあ次は
21:10えっと北郎さんのテストの差分実行という
21:13ことで発表お願いし
21:15[音楽]
21:20ますはいではえっとモノレポにおけるGO
21:24テストの差分実行というタイトルでえ発表
21:26させていただきますよろしくお願いします
21:29えっと自分の名前は鬼太郎と言いますえ
21:32株式会社レアXでえ暴落事業部の申請経費
21:35生産チームで働いていますでま経歴として
21:38はえっと新卒で株式会社メルカリに入社し
21:41てでえっと今年の4月からえ株式会社レX
21:45の方にえ入社しまし
21:48たはいえ今日の目次ですえっとまずこの
21:51えっとスライドのテーマになっている
21:54えっとモノレポにおけるえっと5テストの
21:57差分実行においてっていうなんですけどえ
21:59そもそもモノレポていうのはどういうもの
22:00なのかってのを簡単にご説明したいと思い
22:03ますであとはえっとなぜサブテストがモノ
22:06レポにおいて必要になってくるのかって
22:08いうところだったりとかえっと今回え自分
22:11たちが採用したサブテストのアプローチと
22:14実際にえっとサブテストを適用してみて
22:17どうだったかっていうのとま課題について
22:19えご紹介したいと思い
22:22ますはいではまずモノレポートはという
22:25ところなんですけどえっとこれはサークル
22:28Cのブログの定義が分かりやすかったので
22:30そのまま引用しているんですけどえっと
22:32モノレポとはえアプリケーションや
22:34マイクロサービスの全行動をえ単一の
22:37モノリシックなリポジトリーま通常は
22:39ギットに保存するようなパターンを差し
22:41ますとありますでAXでも大体同じような
22:44え感じになっていてえWebアプリとか
22:47マイクロサービスとかライブラリーとか
22:49スキーマー定義といったものが全て同居し
22:52てるような形になっていますで元々こう1
22:55つのリポジトリーとして作られていた
22:57プロダクトのエンドとかもあるんですけど
23:00まそういったものも
23:01えっと最近はこのリポジトリにえ動かして
23:05きている感じですで具体的にはえっと
23:08レイヤー1というえ大きいモノレポの
23:10リポジトリがあってまその配下にいくつか
23:13えっと言語ごとにディレクトリーが切れて
23:16いて例えばWebであればえっとその配下
23:19にえWebアプリケーションの
23:21ディレクトリーとえライブラリーが含まれ
23:23ていますであとはま5のえっと
23:26ディレクトリーであれば同じくえっとま
23:29パッケージが含まれていたりとかえっと
23:31元々1つのリポジトリーだったえレポスて
23:34いうディレクトリーだとかあとはえっと
23:37マイクロサービスが入っているサービス
23:38ズっていうえディレクトリーが存在してい
23:43ますでえモノレポにおけるメリットとえ
23:46デメリットの例ですえまメリットとしては
23:50まコードや仕組みをえっと簡単に共有
23:52できることだったりとかあとはま全てが1
23:55つに入ってるのでま横断的な改善がし
23:57やすいというところだったりとかあとはま
24:00フロントエンドも入っているのでま
24:01フロントエンドバックエンド関係なくま1
24:03つのプルリクエストでえっとあらゆる
24:05コードに手を入れることができるといった
24:07ものがありますでえっとデメリットとして
24:10はまコードベースがやっぱ全部入っている
24:12のでどんどん大きくなってしまういう
24:14ところだったりとかまえっとテストを全て
24:16実行するとえっとまテストに時間がかかっ
24:19てしまったりとかあとはビルドに時間が
24:21かかってしまうってことがおきますでえ
24:24あともう1つはえっと1つのリポジトリー
24:26を複数人がえ編集するか形になるのでま
24:29コンフリクトがえ増えやすくなり
24:33ます
24:35えでは次にえなぜ差分実行が必要なのかと
24:38いうところについてえご紹介しますえっと
24:42先ほど話した通りま全てのコードが1つの
24:44リポジトリに収まっているのでまポリレポ
24:47に比べて非常にえっとコードベースの大き
24:50さが大きくなっていきますえまそうすると
24:53えっとどんどんテストコードも追加されて
24:55いくのでテストの実行時間っていうのもま
24:58どどん遅くなっていってしまいますでこの
25:00図はえっと過去1年間のえっとテストの
25:04実行時間をま平均化してえプロットした
25:07ものなんですけどこの赤丸の2つのところ
25:10でそれぞれテストの高速化がえ行われて
25:13いるんですけどまただそれをした後もまた
25:15すぐえっとテストの実行時間が増加して
25:17しまっているっていうのが分かるかなと
25:19思い
25:22ますでまえっと今見たようにまある程度
25:25テストを高速化したとしてもいずれまたえ
25:28どんどん遅くなってしまいますでそうする
25:30とまテストコードがどんどん追加されてい
25:33たとしてもま実行時間が比例して伸びない
25:35仕組みっていうのが必要となってきますで
25:37ここで今回採用したのがテストの差分実行
25:41ですはいでは次にえっと実際にえっと採用
25:46したえ差分テストがどういったものだった
25:48のかについてえご説明しますまず前提が
25:52あるのでえっとここに書いていますま1つ
25:55目がえCIでのテスト環境を短縮する
25:58えっとローカルでのテストに関しては個別
26:00に実行できるのでま今回は問題ないものと
26:02してえ最適化をしないことにしましたで
26:06あとはえっと今回は5テストによる単体
26:08テストのみを対象にしていますでえっと
26:12プルリクエストをトリガーとしたテスト
26:13実行にえ適用していますなので例えばま
26:17メインにマジした際とかえっと
26:19スケジュール実行でえマシン屋に動かし
26:21てるようなテストに関しては引き続き
26:23えっと全てテストを実行するような形に
26:26なっていますでえあとはえっとパッケージ
26:29単位での差分実行を行うようにしましたま
26:32別のアプローチとして完成単位で実行
26:35するってのもあると思うんですけどま今回
26:37はえっとそちらの方法は見送りましたま
26:40えっとこれの1番大きな理由としては実装
26:43難度が跳ね上がってしまうっていうところ
26:45ですま逆に言うとまパッケージ単位だと
26:47えっとシトできまし
26:52たでえっとここから実際にえっと大きく3
26:56つのステップに分けてえどういう風にに
26:58差分テストを実行しているのかについてえ
27:00ご紹介しますまず1つ目がえ差分の特定
27:04ですえ今回はえっとプルリクエストのみを
27:06対象にしているのでえプルリクエストの
27:08情報を使ってえサブを取得することができ
27:10ますえっとま実際にはえっとこのGH
27:14コマンドをえ使わずにGHコマンドの
27:17ラッパーの5ライブラリーを使っているん
27:19ですけどえっとこういったコマンドに相当
27:21することをえっとコードで実行していてえ
27:24これによってえっとそのプルリクエストで
27:26え影響を受けた5のファイルを列強する
27:29ことができ
27:32ますでえ2つ目にえ影響範囲の特定ですで
27:37これに関してはえっと性的解析の方を使っ
27:39ていますえっと5の準標準ライブラリーに
27:42え5スラパッケージライブラリーがあるん
27:45ですけどまこちらの方を使ってえ
27:47パッケージの依存グラフを作成しています
27:50でこの作成されたえ依存グラフを元にえ
27:54影響を受けるパッケージっていうのをえ1
27:56つずつ洗い出していくような形になっい
27:59ますでえ3つ目はえテスト実行ですね
28:03えっと2番目のステップでえっと影響を
28:06受けたパッケージってのが全てえ列強でき
28:08たのでまそれを引数に与えることでえ普通
28:11にテストを実行してい
28:13ますでえ効果測定と課題についてですでま
28:19グラフで見てもらうと分かりやすいと思う
28:21ね書いているんですけどま平均で1分以上
28:23高速化することができましたまこの赤丸2
28:26つがえ先ほどのグラフに加えま2ヶ月分
28:29反映したものなんですけどこの1番最初の
28:31赤丸のところでえっと差分実行の方を適用
28:35していますでまそっからえっとまだ
28:38ちょっと1ヶ月ちょっとしかえ計測できて
28:40いないんですけどま今のところは大きく
28:42問題がなく高速化できていたかなと思い
28:45ますはいで実際に得られた効果としてはま
28:48先ほど言った通りテストの実行時間が
28:51大きく改善しましたで依存の少ない変更で
28:54あればえっと2分台とかでテストが完了
28:56するようなこともできるようになりました
28:59であとは複的な効果としてえっと変更に
29:02対して影響のないフレーキテストを回避
29:05できるようになりましたま今まではえっと
29:07全てのテストをえ地位実行していたのでま
29:10その中にフレーキテストが入っているとま
29:12頻繁に全体のテストがこけてしまうって
29:15ことが起きていたんですけどもしえっと
29:17そのフレキテストが今回の変更に影響が
29:19なければえ実行されないようになったため
29:22えっとまそういった落ちるようなケースが
29:24少なくなりましたまただフレキテストての
29:27は絶対直した方がいいなのでえっといずれ
29:30はい1つずつ直していこうと思ってい
29:32ますでえ課題についてもいくつかありまし
29:36たまず1つ目がえっとパッケージ構成に
29:38より大きく実行時間が変わってしまうって
29:40いうところですねま例えばあるパッケージ
29:43に大量の重いテストが入っている時にま
29:45そのパッケージにちょっとした変更する
29:47だけでもまそのパッケージにに影響があっ
29:50たという風に判定されてしまってえ思い
29:52テストを全て実行しないといけないという
29:54ことがえ起きますでもう1つねの方が
29:58えっと外部パッケージの変更をどう扱う
30:00かっていうところですねでこれに関しては
30:02えっと現在はGO.modのファイルが
30:05更新された時はえ一律全てのテストを実行
30:07するような特殊な処理を入れてい
30:11ますはいまとめですえレイアXのモノレポ
30:15ではえテストの実行時間がえ課題となって
30:18いましたでこれに対してえ差分実行を
30:20取り入れることでえ改善を測りましたで
30:23具体的には変更ないように影響される
30:25パッケージの身をテストするという手法
30:27ですでこれによってえっとテストが1分
30:30以上高速化できたのとあと今後テストが
30:33増えていったとしても実行時間の増加が
30:35緩やかになるはずですで差分実行の課題と
30:39してはえパッケージ単位なのでテスト対象
30:42のパッケージによっては引き続き時間が
30:43かかってしまうっていうことがありますま
30:46ただえっと現在ここが深刻な問題にはなっ
30:49ていないのでえっとしばらくはこの方法を
30:51採用し続けるかなという風に思っています
30:55はいちょっと駆け足になってしまったん
30:56ですけど発表は以上となりますもしえっと
30:59詳しく知りたい方がいたら今心会でお話し
31:02しましょうありがとうございまし
31:07たはい太郎さんありがとうございました
31:09レポ快適なんですけどこういうなんか
31:12困り事がぼちぼちあるんで早くなったら
31:14嬉しいのとあと皆さんフレキテスター直し
31:17ましょうはいじゃあ次はえっと内生
31:22オブジェクトストレージB3B3を支える
31:24ミラティブの合技術ということでうさん
31:27発表をよろしくお願いいたし
31:33[音楽]
31:39[音楽]
31:56ますはい
32:05[音楽]
32:09えっとはい出てます
32:12[音楽]
32:17ね
32:22えっと来てるあそうか刺さなきゃダメじゃ
32:25ないですか
32:32これ
32:35かはいはい大丈夫そうですねよかったはい
32:39えっとじゃあちょっとミラティブからこの
32:41動画発表させていただきますえ福岡から
32:45今日来まして普段は5でみのを開発したり
32:50していますあと本本訳しましたえ今日は
32:54あのオトスージを内した話をします一応
32:58ソフトウェアの名前はB3と言いますはい
33:01ちょっとアジェンダは書いてある通りでま
33:03ザクザクと言えければなと思いますはいで
33:07まずそもそもオブジェクトストレージを
33:09使っていますよね皆さんま最近の
33:13インターネットつではそれをま使うなとか
33:17作るって何みたいな感じだと思うんですよ
33:19ねあのまず配としてミラティブていう会社
33:23の結構固有な事情というかありましてあの
33:27ライブ配信の
33:28サービスなんですねミラティブってちなみ
33:32にミラティブってサービス自体にご存じの
33:34方ってどれがいますかありがとうござい
33:36ますあの遊ばれたり配信されたりしたこと
33:39ある方ってもしかしていらっしゃいますか
33:42そうまさすがになんか若者が結構多い
33:47らしいでえなんでもないですそそうZ世代
33:50のZ世代の方とかが多いと聞いてるんです
33:53けどはいまあでも
33:55配信あのライブ配信って大量いろんな
33:59ファイルを配信してるんですよねまなんか
34:02配信がダブルメニュですけどなんかなんか
34:05画像とかまそれこそ動画録画色々配信して
34:09ますでその中で配信をしたら録画すること
34:13ができる機能があるんでその話がメインに
34:15なりますで録画した録画のあの動画
34:20ファイルをHSという形式で配信してるん
34:23ですよねでこれは要するにプレイリスト
34:27ファイルから小さいチャンクの動画
34:29ファイルを1個1個落としてクライアント
34:31で落としてくっていう感じなんですけど
34:33ポイントは動画をま細かく切って小さ
34:36小さいファイルたくさん使ってるところに
34:37ありますでちなみにあの動画普通に
34:42ダウンロードボタンを押すと結合された
34:43動画が帰ってくんですよねこれもまず録画
34:46で小さく切ってからくっつけて結合して
34:49MF4として返していたりしますはいで
34:53HSだからこういう感じでHSっていう
34:56形式でやるとファイルがとても小さい
34:58ファイルをたくさん扱う必要があります
35:01そうするとどうなるかって言うとま一般的
35:04なパブリッククラウドのオブジェクト
35:05ステージだとちょっとあの相性が悪い
35:08ところがありまして具体的にはまあの
35:12オブジェクトステージの課金があの容量
35:15以外にもえ例えオペレーションにも課金さ
35:17れるというのはご存知だと思うんですけど
35:19これが例えばま2gの録画のファイルに
35:23対してま2万回2万個2万個に分割して
35:27プッシュしてでダウンロードする場合も
35:292万回のあのゲットオブジェクトが走る
35:31みたいな感じでちょっと細かい操作が
35:33たくさんんであの容量に対して費用は重ね
35:37がちという問題がありますま色々ま
35:40チャンクのサイズを調整した色々CDのを
35:42そもそも使ったり工夫はしてるんですけど
35:45もう少しいい感じにできないかなという
35:47ところでままずは例えばま飛行実験的に
35:51オブジェクト正治を自前で自前でサーバー
35:54立てて何かサーバー立てて運用するとし
35:57たらそのオペレーションごとの費用はいま
35:59全部なくなるわけなんですね純粋にま
36:03CPUとハードディスクの値段だけになる
36:05とまあとまハードウェアがま自分でれるの
36:08で色々工夫できるんじゃないかなってこと
36:10でオブジェクトスページをあの自前で
36:14やろうという話が出てきましたで要件を
36:17少し整理するとまバックアップとかの話は
36:20するんですけど今回主に3つに絞ってあの
36:23まずファイルは一定期間しか保持しないと
36:26いうことにしていますまこれは例えばあの
36:28ユーザーさんの録画は3日しか保持しない
36:30とかそういう感じで制限ができるものなの
36:33でま逆に言うと無限に容量をあの溜め込ん
36:36でいくっていう答にはではないって感じ
36:40ですでま逆にでさらに言うと一定期間しか
36:46保持しないということは一定期間後に削除
36:47するということでもありますでなおかつ
36:50先ほど言ったように書き込みの操作が
36:53すごく多いんですね15秒ごとにちゃ切っ
36:56たとしたら当然ですけど15秒ごとに
36:58フットオブジェクトが走るとなのでしかも
37:01な何台も並列で走るはずなんですねなので
37:05たくさん書き込まれるっていう前提で工夫
37:07する必要がありますで最後にあのまIO
37:11ベアメタルだったり自分自前のあの
37:14インスタンスを管理するのででiをなんと
37:17ちゃんとコントロールしないといけないと
37:19いうところはありますあのま普通にえ
37:22ハードディスクの限界以上の愛が来て
37:26しまうとまってしまうとかIが
37:29めちゃくちゃ溜まるとか問題が起きますし
37:31ま公述するようにあの内部操作でiが
37:34大きいものもあるのでそういう即事性を
37:36求められないIを分けるとか色々やる必要
37:39があります他にもまあのハードディスクと
37:42ソフあのソリッドSSDを使い分けるとか
37:45色々やりたいことがあったりしましたで
37:49最初はま当然自前よりもまあのミニオだっ
37:52たりCだったりま色々あるんですけどいく
37:55つかosssのものを試したんですけどま
37:58検証結果はブログ
38:01を書いてるんでそちらにを後で参照して
38:04欲しいんですけどま基本的にはあの特にミ
38:06は実際にファイルを作ってしまうので
38:10書き込みがちょっと弱いなとかあとま
38:12さっき言ったバキみたいなあの圧縮操作が
38:15ちょっと遅くなるとかちょっと要件に合わ
38:18ない感じがしたんですねなのでちょっと
38:20自前で開発を考えてましたということでb
38:243って言んですけどま基本的な機能はS3
38:285かのhttpAPIっていうとま
38:31レプリケーションとア制御という感じです
38:34なんで概要なんかこんな感じでhttp
38:38APIの層があってその使用にバケットを
38:40コントロールするコンポーネントがあって
38:43あのディストリビュートってそう1個挟ん
38:45で実際のDBファイルになってるなって
38:48いるとでこのDBのファイルのデータ構造
38:52にまず工夫がありますあのこのデータ構造
38:56はあのライトヘッドルグ割とLS3
38:59インデックスをベースにしたものなんです
39:02ねまこれ横文字で言われてもよくわから
39:05ないかなと思うんですけど要するに書こ
39:07全部基本的に全ての操作は基本的に追金に
39:11なってるっていうものですま図すると
39:14こんな感じでまデータ123と書きあの
39:19まみどんどん追されていくんですけどこの
39:21時にアップデート操作も同じキでの追求だ
39:24し作者も作者マークのええデータの追って
39:28感じで全部追で表現してるんですねそう
39:31するとあのまハードディスクとかはシシル
39:34書き込みでやれば結構パフォーマンスが
39:36出るんでそういう風に最適化された操作が
39:39できるとでインデックスを別に持っておく
39:42んですけどまちゃんと操作を操作上から
39:45どんどんヘッただけ飼育して戦闘会
39:48読み直すばインデックス採構築はできます
39:52はいでなおかつデータにヘッダでベッド
39:56あのを持たせているのでまあの
39:59バキューム操作って言うんですけど
40:02あのんですかね定期的にパージまトム
40:07ストーンあの削除マークトムストーンを
40:10置いていって
40:13えその上で元のDBとなんですかねまこ
40:18この見た方がいいなえっと景的にデータシ
40:22を行っていてあの応の不要領域の部分を
40:27無視してあの緑の生きてる領域だけを別の
40:29ファイルに一旦全部コピーしてから
40:31アトミックに置き換えるっていう感じで
40:33あの定期的なデータシが可能になってます
40:37はいで一応やっぱり普通にファイルを
40:41なんか作り続けるよりも追で書き込む方が
40:44早いというのも早いというのもちょっと
40:47軽くあの過去の発表で検証していますま
40:50システムコーとかもすごく減りますで次は
40:545らしい話を少しするとなんか内部で
40:57リーダーと
40:58ライターであのちょっとコドを綺麗にする
41:01工夫をしていますまこの2つの
41:04インターフェイスは5の1番基本となる
41:06インターフェイスなのでちょっと説明は
41:09省きますが例えばTリーダーってのがあっ
41:13てオブジェクトをプットしたら一緒に発値
41:16を計算してあのEタグの値を計算しないと
41:19いけないわけですねオブジェクト
41:20ストレージなんでそれもあのTリダーで
41:23あのDBDBとMD5の計算構造体の両方
41:29をくっつけてまとめてプットするみたいな
41:32ことをすればあのま両方に同時に書き込む
41:35のであのスマートに端が計算できるみたい
41:39なことができますあとまあの内部で対の
41:44ファイルな場合とファイルていうか対日の
41:47オブジェクトの場合と複数のオブジェクト
41:48をくっつけてる場合ってのがあのママチ
41:52パーとAPIを実装する都合で存在してる
41:54んですけどもそれもIリーダーでッする
41:57ことであのゲットオブジェクト側の実装は
42:00あのま1個の1個のFだけでまとめるよう
42:03にしたりして
42:04ますはいこんな感じであの
42:07インターフェイスを工夫してんですねで
42:09もう1つがI制御をしていますこあの
42:14要するにいわゆるIシェーピング
42:16をしていますでこれにはえあののタイム
42:21レイトライブラリってのがあるんでそれを
42:23使っていますなんていうかこんな感じで
42:27リミッタっていうのを作って
42:31あの最大どれぐらいっていうのRで指定し
42:35てあのリコピーNのコピーNのループで中
42:38で
42:39えっと書き込んだ数だけウイNを呼び出し
42:42てあげるとまポイントポイントで回の
42:45レートリミットできるみたいな使い方が
42:46でき
42:47ますまこれはあのさっきさっき紹介した
42:51ビッキスクDBってやつのあのの
42:54バキューム操作ってたくさんコピーをする
42:55んでたくさん用が発生するんですよねそれ
42:58をあのまあのアリミッターじゃないです
43:01けど内生のリミッターで10m秒と30m
43:04秒であの実行したあのその結果のタット
43:09経由の結果ですちゃんと制限あの一瞬だけ
43:12バーストしちゃうんですけどどうしても最
43:14ちゃんと制限できてることは確認できます
43:17はいでここまでね時間
43:21がああと2分ですかねなのでこうあの
43:27ちょっとロックをロックを小さくするため
43:30にDBを内部であの分割してるんですよね
43:33とかいう話を軽くするとあのDBの分割に
43:37あの基本的にただキーバリストアなんで
43:40キーをコンシステンシーを使って後ろの
43:43DBに振りまけばあの分割できますよって
43:47話をしたかった感じです
43:50はいえっとてかあの正直10分ではは語り
43:55切れないトがいっぱいあってあのラッツの
43:57話とかあとアダプティブLAD3とか色々
44:02やってるんですがあのちょっと気になった
44:04話があれば心会で教えてくださいで最後に
44:08軽くまB3の振り替えなんですけどあのま
44:10さっきアたのB3じゃないですはい
44:14えっと一応録画アーカイブダウド機能は今
44:17100%B3ユーザーさんの実際の録画の
44:21アーカイブをBに乗っけていますはいでま
44:24今とま問題なく運用できてる感じです問題
44:26は全部してますで録画自体の
44:30あの保存もB3にしようと今え検証中です
44:36で某でやっぱア作るのってすごく有性がる
44:39なと思ってて基本的な道具が揃っている
44:42あと文法がシンプルなんでアルゴリズムを
44:45素直に実装できるその上でまあの普通に
44:47書いたらかなりパフォーマンスが出
44:48るってのは魅力的だなと思いましたはい
44:52なんでまちょっと色々工夫アルゴリズムや
44:56データ構図色々夫をしていったらま
44:58オブジェクト正助ある程度内生もでき
45:00るってことをあの今回お伝えしたかった
45:02です
45:04はいまそんな感じでご深掘りした人を募集
45:07してますああとあなんか8月19日私東京
45:12来るんであでもこれマニオらしいですけど
45:16あの少し拡張するという話もあるんであの
45:185もいいけどebpfもよろしくお願いし
45:20ますありがとうございました
45:23[拍手]
45:33らさん発表ありがとうございました結構
45:36オブジェクトストレージのlsm釣り回り
45:38はあのデータ試行アプリケーション
45:40デザインで読んだやつだってなったんです
45:41けどちょっと気になること色々あるんで
45:43今心会で聞いてみたいと思いますはいでは
45:46次は5で実装された高速なAWSCL1
45:49大体品を作ったということでフジさん
45:51よろしくお願いいたします
46:05はいこれ配信映ってますかね大丈夫大丈夫
46:09ですかはいえじゃあ始めますえ5で実装さ
46:13れたawcの代替品を作った話をしますえ
46:16自己紹介藤原ですこんなアイコンでSNS
46:19ではいると思います面白方人火というとこ
46:21におりますえイスコンを昔からやってて1
46:24回目からえっと優勝を4回したりととか
46:27運営を4回したりとかしててえイスコン
46:29今年もあるみたいで本当良かったですね
46:31はいであとosssを作っててえカヤの
46:34エスプレッソっていうやつあのレイヤX
46:36さんでも使われてるらしくてありがとう
46:37ございますあとラムロールっていうラム
46:39ダウンデプロイするとかえを作ってたりし
46:42ますあと本を強調でいくつか昔もう結構前
46:46ですけどみんなの合言語っていうのも書い
46:47てますはいでえっといきなり本題なんです
46:51けどawcってあのAWS使い方皆さん
46:54あのご利用だと思うんですけどこれ
46:55とっても重いんですねでどれぐらい重い
46:58かって言うとえヘルプを出すだけで1秒
47:00かかるっていう重さでえしかもこれCPU
47:02バウンドなんですよ通信とかじゃなくて
47:04CPUをめっちゃ使うのでえまたまに手元
47:07で打つのは別にまあ1秒かかってもそんな
47:09にいいんですけどこれをシレスクリプトに
47:11組み込んでぐるぐるループを回したりする
47:13と毎1回1秒かかるんですねあと最近その
47:15ECSとかラムダとかで結構CPUが1は
47:17ない環境ってのもあってコスト減らすため
47:19にえ0.25vcpというとこれ1/4個
47:22はしかないので1秒かかることは4秒
47:23かかった3秒かかったですえでこういう
47:26ことがあるとあの本当にちょっとしたこと
47:28をCLでやりたいだけなのにこれが3秒
47:32かかったらこ辛いわけですねでえこういう
47:35時僕はあのAWSsdkと5を使ってま
47:39コード書いてたんですけどそうすると
47:40すごい早いのでただそのいちいち書くとね
47:43あの大変ま何十行ぐらいかになるしビルド
47:46もいるしめんどくさいんですよでAPI個
47:491個呼ぶだけとかなんかモニタリングの
47:50ために1個メトリックトだけとかそういう
47:52ことをするのにですね全部いいここで
47:54書き直すのも面倒くさいということがあっ
47:56てえまこれ多分AWScliを使っと5を
48:00使ったことがある人が100人いたら
48:02100人思ってるはずだと思うんですけど
48:035で実装したシングルバイナリーして
48:05欲しいなとあのpyonなんですね今の
48:07フト実装はね思ってるはずだと思ってます
48:11でえである日ねちょっと気が付いたんです
48:14けどなんか行動の呼び出し方みんな一緒だ
48:16なみたいなsdkのえS3でもこれSSM
48:19の例書いてますけどニフコンフィグして
48:22そいつに対してAPIを読んでそのAPI
48:24の読み方がコンテキストとえなんとかイン
48:26ットってのを渡すでなんとかアウトプット
48:29が書いてくるこれの構造が全部一緒で命名
48:31規則も全部一緒なんですよえでこの下にま
48:34ちょっと雑に書いてますけどで全部これ
48:36一緒だからえこれ同生成できるんじゃない
48:39かということをふと思いついてでえつまり
48:42このsdkのですねえサービスパッケー
48:44ジってとこにいろんなエスのサービスを
48:46呼び出すえ3だとかECSだとかEC2だ
48:49とかあるんですけどこのパッケージないし
48:51て全部同じ方でクライアントなんとか
48:53クライアントってのがあってその
48:55クライアントに対して全部同じ方形で
48:57呼び出せるのでこれはもうあとはメソッド
48:59一覧だけ全部なんとかして取り出せたら
49:00コードが自動生成できるなと思いついたん
49:03ですねでえまチャットGPTに聞いたん
49:06ですよねうん聞いたらあのこんな風に書け
49:08ばできるよってのすぐ出してくれてこれ
49:09あのリフレクトを使うんですけど
49:11リフレクトを使って
49:12えそのなんだクライアントオブジェクト
49:16からメソッドを取り出してメソッドの名前
49:18とか方とか引数の方とかそういうのを
49:20グラグラグラっとこう取り出してくれるま
49:23これあの聞けば出てくるような行動です
49:25はいということでええあとですねその引数
49:28を出さなきゃいけないじゃないですねあの
49:29API時にえいろんなawcあったら
49:34コマンドライン引数で渡すような引数を
49:36渡すんですけどまそこを解釈するのが面倒
49:39くさいのでえとりあえずJSでいいやろう
49:41とえどうせあの1つのオブジェクトになっ
49:44て1つのオブジェクトになって帰ってくる
49:45のでえJSONを渡してそいつをアン
49:47マーシャルしてその方にバコと入れてで
49:50それでえコードをサービスのコードを
49:53呼び出してアウトプットをジェソンで
49:54マーシャルして返してやればえどっちも
49:56えっと場バイトを取ってバイトを受け取る
49:59変えてくるっていうコでできるなという
50:02ことでこんな風なコでこれあの5の
50:04テンプレートを使ってそれにさっきの
50:06メソッド1段とかの情報を食わせて
50:08ぐるぐるぐるっと回すとコードがダーと
50:10できるとでできたものがこれですえっと
50:13osimというやつがありますえこれはま
50:17その単純なAWSsdkのラッパーだよっ
50:19てことになってますでモチベーションとし
50:21てはえcliはとっても便利なんだけど
50:24ちょっと遅いんでえ限定的なええまやつを
50:27作ったよということですねで使い方ですえ
50:31AWSコマンドじゃなくてオス
50:33STREAMコマンドになってあとその次
50:35にサービス名ですねSTSゲットコーラー
50:37アイデンティティっていうあのこれは僕が
50:391番好きなコマンドなんですけどえま何を
50:41するかをちょっといいとしてえまこれを
50:44呼ぶ時には普通にAWCLみたいにえ2番
50:47目の引数にサービス名次にメッドってやっ
50:50てやれば呼べますでこのメソッドがあの
50:52パスカル計算なのはももsdkのメソッド
50:55をそのまま使えるようにしてるからなん
50:57ですけどえそこにちょっと変換できるよう
50:59にしてあってあのケバブケースでも
51:01受け付けるようにするともうものすごく
51:02エベスCLっぽくなるでさらにえ先ほど
51:05言ったようにあの引数が必要なやつですね
51:08インプットが必要なやつはJSONで渡す
51:10ことになってんでJSON文字列かJS
51:12ネットの文字レスのを渡してくださいって
51:14いうちょっとこれ使いにくい感じがします
51:16よねこれ1個ならいいんですけどいっぱい
51:18やるとここにJS文字列をずらずらと書か
51:20なきゃいけなくてちょっとめどくさいなと
51:22いう感じなんですがえ実はですねあの今朝
51:25を思いついて今日実装できたら来たんで
51:26あのリリースしたんですけどえこういう風
51:28にクラスターみたいなえっと2位の
51:31コマンドライン引き数で値を埋め込める
51:33ようになりましたただあのちょっと現時点
51:35ではまだあの文字列しか入らないので
51:37マックスリザルト10みたいなあの数値が
51:40必要なとこはちょっとまだできないんです
51:42けどまそのうちなんとかしようと思って
51:44ますはいとなるともうこうなるとほぼエス
51:47Cと一緒みたいなことになりますねで
51:48スークはジェソンでエシラみたいな
51:50ジェソンが降ってき
51:51ますはいでえ課題なんですけどえバイナリ
51:54サイズがでかい問題ってのがあってえス
51:56ムって言ってるのに全然スリムじゃないっ
51:58ていう問題があるんですけどえ500
52:00mbb以上ありますでなんでかって言うと
52:02あのAWSsdkのサービスって今数え
52:05たら384サービスあってえそれを全部
52:08あのそれのさらにその全部のメソッドを
52:11コド生成で生成してビルドして詰め込ん
52:14だらこのサイズになってしまってあの
52:15ビルドがしかも5なのに10分かかります
52:17えでえっとADcliはチップ展開口に
52:20125mなので倍ぐらいなんでちょっと
52:22これはちょっと悔しいとことですねという
52:24ことであのどうせ全部使うことはないので
52:26特定サービスだビルドできるようにしてみ
52:28ましたっていうのであのこれだけ使いた
52:31いってのを指定してビルドするとこれだけ
52:32組み込んだバイナリーができるであの僕が
52:35ちょっと使ったことがある40サービス
52:36だけで作ったら92MBになったのでま
52:39こんぐらいなら強要範囲かなぐらいですね
52:42でビルドの方法ちょっとあのドキュメント
52:44書いてあるので見てもらいたいんですけど
52:45どっかでやると4秒ぐらいでできますはい
52:48でパフォーマンスの比較なんですけどどれ
52:50ぐらい早いかって言うとえこれは0.25
52:52vcbのわざと細いところでえタイム
52:55コマンドをわせて比較したんですけど
52:57awcはCPU時間が760MSで実質
53:01時間はその4倍なので3秒かかりますえで
53:05スリムは全部入りのそさっきの500
53:07mbbのやつでもえCPU時間が110
53:10MSですね大体7倍速ですね7倍のCPU
53:13勝率でできるただメモリがちょっと多くて
53:15メモリが倍くらい食っちゃうんですよ全部
53:16リだとでこれを40サービスに絞ると
53:19もっと早くてえま実時間でもあの10mm
53:22セックとかで書いてくるでメモリも少ない
53:25ということでえ非常に効率的に動くように
53:27なってますはいであと便利機能色々時間
53:30大丈夫かなはいえっとあのhelpsdk
53:34のドキュメントURLがまると出るように
53:36なってますはいこれとても便利であのこれ
53:38をポチっと開くとですねあのブラウザで
53:40見ればいいあの全部sdkのラッパーなの
53:42で自分で確率ないんでこれですねあと
53:45クエリーてあのジェムスパァスってあのバ
53:47シリアにあるやつとえっとローっていう
53:50あのJQの配Rローアウトプットと同じ
53:52ようなのが入ってるんでえ具体的にやると
53:55あのこれは僕はすごくよく書くコードなん
53:58ですけど自分のアカウントIDを知りたい
54:00時のコードですねえゲットコール
54:01アイデンティティを読んでその中の
54:03アカウントっていう要素を取り出してきて
54:05それをロケ式でやってやるとシェル編数に
54:07アカウントIDが入りますよってやつ
54:09コードはいであとインプットSTREAM
54:11とプットスムとがあってこれはですねあの
54:13まつさんが先にあの最初に出した時に
54:16フルリもらっておっと思って考えて入れた
54:18やつなんですけどえこれはあのS3の
54:21プットとかゲットの時ってIOリダーとと
54:24iioリードクローザーがあのストラクに
54:27入ってんですけどまそれを使ってファイル
54:29をアップロードするさっきもありましたよ
54:30ねあの
54:31Iリーダーを使ってやるとなんだ小
54:35メモリーでできるって話がありましけどま
54:36それと同じ話ですねまこれを使うとえ
54:40ファイルこれとファイルをくっつけて
54:42くくれるのでえ要するにプット
54:44オブジェクトとゲットオブジェクトが
54:45できるこですねはいえであとフォロー
54:48ネキストであのページングがあるAPI
54:49ってあると思うんですけどあの1ページに
54:51は1000件しか来なくて次はこれこの
54:53トークンを食わせてやると次のページが
54:55取れるよっっていう例えば3のリスト
54:56オブジェクトみたいなやつこういうやつは
54:58あの自動で追ってくれるような
55:01え引数をつけてありますえこれあのどの
55:05引数がどのフィールドがっていうのが
55:07サービス生全部違うので自分で指定し
55:08なきゃいけないんですけどあのS3だっ
55:10たらNEXTコンティニュエーション
55:11トークンっていう値を次のリクエストの
55:13コンティニュエーショントークンに入れて
55:14やると次のページが取れるみたいですねで
55:17これは内部でループするので高速ですはい
55:21えあとJSネット感想ちょっとこれはいい
55:23やはいえっとあとですねえっと設定
55:27ファイルを作れるようにしていてオープン
55:29コマンドを指定しておくとヘルプの時に
55:31ブラウザがボンと開いたりだとかあとア
55:33ですねあのえっとですねsdkとcliで
55:37コマンドが違うやつがあってログスcli
55:40だとAWSlogsなんですけどえSD
55:42ギアAWSあosimCloud
55:45WatchログログスなんですねとかCE
55:47がコストエクスプローラーだったりとか
55:49ちょっと違うのがあるんでこれはエアで
55:51ちょっと自分で解決してねってことにして
55:53ますあと短縮が名ができるのでフアIとか
55:57やるとえ同じことができるはいで
56:00オプションを組み合わせるとですねS3
56:01プットとかS3ゲットができるようなやつ
56:03がコマンドができたりとかですねえあと
56:06ちょっと複雑な例なんですけどクエリーと
56:08かをうまく組み合わせてえリスト
56:10オブジェクトV2のえぐにょぐにょぐ
56:13にょってやるとえ要するにS3のリストが
56:16取れるようなコマンドができるはいという
56:19ことであと最後これこれだけえっと
56:22ちっちゃくなんないかなと思ってupxを
56:24使ったんですけどちょっと微妙な結果に
56:25なっちゃったんでえこれはちょっと要研究
56:27かなっていう感じですはいえじゃあまとめ
56:29ですえっとスリムていうのを作りました
56:32起動速度は7倍でえ早いですあと必要な
56:35サービスだけ見るとするとちっちゃくなり
56:37ますということでえサーバーで使う場合は
56:39これはおすすめなのではいどうぞって感じ
56:41ですねえあと今日リリースしたやつで文字
56:43列をフラグで渡せるようになってすごく
56:45便利になりましてえ便利機能を
56:47組み合わせると最強コマンドが構築できる
56:49ということですねあとえっと最後にこれは
56:52ADSにお願いしたいんだけど公式が豪華
56:54ラスで実装してくれたらこれいらなくなの
56:56でえんとかしてくれと思ってますはい以上
56:59[音楽]
57:00[拍手]
57:04です藤原さん発表ありがとうございまし
57:07たすごい追従大変そうと思ったんすけど
57:11自動生成が使れてすごいいい感じなんで
57:13ちょっと私も明日から使いますはい皆さん
57:17発表ありがとうございまし
57:22たで会前にちょっとおらなんです
57:27けどはいえっと8月ニモさんとえ車AXで
57:335合同イベントやりますでえっと8月9日
57:387時からえこのオフスでやるんでえっと今
57:42すぐカレンダーに予定を追加しておいて
57:44くださいでえっとまだイベントページでき
57:47てないのでえっとレXの公式テック
57:50アカウントあとニさんのテックアカウント
57:52もあると思うんでえっと2つフォローし
57:54てれば絶対分かると思うのでえ今すぐ
57:57カレンダーに予定売れて今すぐ公式のテク
58:00アカウントフォローしてくださいはいお
58:03知らせでしたではい最後にあの今新会前に
58:07アンケートがあるので是非よろしくお願い
58:10し
58:11ますQRコードを読み取ってアンケートに
58:17回答よろしくお願いし
58:21[音楽]
58:22ますえ皆さんがアンケートに答えて
58:25くださっい間
58:27にどうしようか
58:30な松さんどうでした
58:33かPGの話をしてくれた岩松
58:43さん自分今日初登壇でめちゃめちゃ緊張し
58:47てたんですけどま登壇終わった後はすごい
58:49気楽に聞けてめちゃめちゃ面白い話が
58:51たくさん聞けたのではい楽しかったです
58:53ありがとうございましたありがとうござい
58:55ます
58:58なかなかPGO実運用でやってるって話
59:01あんまり聞かないので是非今新会でPGO
59:04の話聞いてみてくださいはいじゃあ
59:07アンケートはいじゃあ皆さんあのドリンク
59:10とフード後ろに用意してるのでアンケート
59:13を記入しよった方から是非あの皆さんで
59:16公式会でワイワイしましょうはいオン
59:18ラインの方はここまでですねはい皆さん
59:21ありがとうございまし
59:22[音楽]
59:25たJA

About this transcript

This page contains the full transcript of layerx.go #1 〜最適化・効率化〜 by LayerX 公式, generated from the public captions YouTube serves with the video. The transcript has 1,284 words across 1,284 segments, with the original timestamps preserved so you can click any line to jump to that moment in the embedded player.

What you can do with it

Use the transcript to take notes, quote the speaker, build a study guide, generate a summary with ChatGPT or Claude via the YouTube Summary tool, or export it as a timed subtitle file with YouTube to SRT. You can also re-open it in the transcriber to translate the transcript into 100+ languages.

Free YouTube transcript tool

YouTube2Text is a free YouTube transcript generator — no signup, no daily limit. Paste any YouTube link and get the full transcript instantly, with timestamps, click-to-jump, translation to 100+ languages, AI prompts for ChatGPT, Claude, and Gemini, and exports to TXT, SRT, VTT, or Markdown.