備忘として書く。
エラーログを見るのはよくあること。何年も経験している専門分野ならまだしも、残念ながらなかなかそういう事がない。経験の少ない分野でエラーが出ると不安になる。
エラーを調べて対策をとる、という流れがまた大変。
観察、分析、仮設、検証をぐるぐる回転させる、学校の理科の授業みたいなプロセスが大変。だがChatGPTは、どうもこのあたりを爆速にしてくれる効果があるように思う。特にコンピューターソフトウェアの分野については、異常に効果がある。
人間の哲学とか、人生の方針を決めることについてはまだまだできない（というかそれができたら、即ターミネーターの未来になるだろう）が、ソフトウェアのエラー対応や定義など、決められた枠組みに対して、AIはものすごい効果が得られる。基本は計算機なので、それは当然なんだけど改めて気がつかされた。ただ、たまに意図せず嘘を答えるので、そこは検証が必要。
例
Fluentdで、こんな感じのエラーが出て困ったことがあった。
[warn]: #0 failed to write data into buffer by buffer overflow action=:throw_exception
バッファーオーバーフローしてデータが書けないというのはわかるが、じゃあどうすればいい？と。いつもならGoogle検索だが、ここをGPT先生に聞いてみる。
なるほど、これはFluentdにバッファを調節するパラメータがあるということか？
というわけで、1.の解決策があるのか、それを聞いてみる。
ここまで来ても怪しいので、公式の文献を確認する。
chunk_limit_size [size]
Default: 8MB (memory) / 256MB (file)
The max size of each chunks: events will be written into chunks until
the size of chunks become this size
どうやらそのパラメータはあるみたい。が、全部英語。
いつもならここでDeepL先生の登場だが、今回はそれもGPT先生に聞いてみよう（長文読解0点派）。
⇒なんか合ってるっぽいね
溜まったチャンクとして溜まったバッファの上限を増やすから、暫定的にはいいんじゃないかと。
そもそもバッファの仕組みとかってなんなのか？これは公式から確認。
https://github.com/fluent/fluentd-docs-gitbook/blob/a50cb1d564e1285c59b91c7fade2bf80f05394ce/images/buffer-internal-and-parameters.png
受け皿を増やすようなイメージと。
一応、本も読んでチェックしてみる。
Fluentd実践入門 ── 統合ログ基盤のためのデータ収集ツール (WEB+DB PRESS plus)
https://www.amazon.co.jp/Fluentd%E5%AE%9F%E8%B7%B5%E5%85%A5%E9%96%80-%E7%B5%B1%E5%90%88%E3%83%AD%E3%82%B0%E5%9F%BA%E7%9B%A4%E3%81%AE%E3%81%9F%E3%82%81%E3%81%AE%E3%83%87%E3%83%BC%E3%82%BF%E5%8F%8E%E9%9B%86%E3%83%84%E3%83%BC%E3%83%AB-WEB-PRESS-plus/dp/4297131099
⇒そのパラメータの意味と効果が書いてあるので、なんか合ってるっぽい。
AIだけでなく、他になにかあるが、自分でもググって調べてみる。
- あと2時間でElastiCacheのメモリが枯渇！そのときあなたは何をしますか？
https://zenn.dev/e_koma/articles/20201218-adventcalendar-1a8e2ea4#%E5%AF%BE%E5%BF%9C-4
fluentdのログを調査したら、BufferOverflowErrorが出まくっていました。BufferOverflowErrorはfluentdの bufferファイル出力より fluentdへの入力が大きい場合などで発生します。file bufferを見ると、timestampが1時間とか2時間前のファイルが大量に溜まっていたので、完全に入力の方が大きく詰まっている状態だと判断しました
またworker数を見てみると、1workerで動いており、workerを増やすともう少しリソースを効率的に使えスループットが上がりそうでした。が、オンラインでいきなりmulti workerに変更するとfile bufferのパスが変わり、変更前に貯まっていたbufferが送信されないリスクがあるので、multi workerは今後のメンテ時に対応してもらうことにしました。
なるほど、動いてるワーカーが少ないと。たしかにワーカーはデフォルト値だったので、1で動いてるので、これをマルチに動かして水平展開させれば処理できる量も増えると。
この辺で対策が見えてきた。
- バッファできる量を増やす
- 処理するワーカーさんを増やす
これをすることで対策ができそうだと。なおかつ、クラウド環境であればそのマシンのスペック（特にメモリ）を上げることも足してみると。
※根本的には来る流量を調整しなきゃならんが、そういう大きい流量だから難しい。
ちなみにファイルバッファも出しているので、それがたくさん未処理で詰まっていると。どう消せばいい？聞いてみよう、先生に。
というわけで、GPT先生に聞いた内容と調べた内容を試してみたら、暫定的な対応を打つことができ、おおよそ解決した。
感想
仮設と検証するプロセスがとてもラクになった。人間に必要なのは、AIが出した回答に対する、検証、見極めと、意思決定、他に代替案を見つけること。これを繰り返すことで、真の原因にたどり着くまでのプロセスが爆速になる。AI凄い。
こりゃ俺の仕事なくなっちゃうかもな、と思いつつ。
とはいえ、頼れる味方ができたようで、新しいことをやるリスクや、何かあったときのリスクがだいぶ軽減されたように思う。AIが発展することで、人はどんどん新しいことをやっていくんじゃないかな？と感じる。それはそれで楽しい。そしてそれはとても面白い。
AWSやAzureなどクラウドをやったときも、先輩が「これはエンジニアをダメにするやつや・・・」と言ってたけど、またしてもエンジニアをダメにするやつが出た。でも物は言いよう。ダメではなく、便利になったんです。便利。怠惰であれ。
プログラマの三大美徳とは？
https://it-kyujin.jp/article/detail/2006/
「全体的なエネルギー削減の為に努力を尽くす気質。その気質があれば労力を減らすプログラムを作ることで皆に役に立てたり、余計な質問をしなくてもいいようにドキュメントを作成することができる。故に、第一のプログラマの美徳である。」
- 注意
個人情報などはプロンプトに入れないように、ログの一部だけを抜き取って、実行することが大切。翻訳のDeepLなんかも同じく。気をつけていきたい。
余談
タモリ俱楽部がついに終わってしまった。仕事で煮詰まったときに、空耳アワーを聞いてリセットしてた私のような人はどうすればいいのか。存続を希望したい。