ChatGPTのビジネス展望

Imagination in Actionは、2023年4月13日にマサチューセッツ工科大学のSamberg会議センターで開催されるAI技術イベントです。
AIアプリケーションに関する基調講演やパネルディスカッションを通じて、
スタートアップ、創業者、起業家が成功するAI会社を構築するためのインスピレーションが共有されました。

OpenAIのCEOのSam Altman氏のBreakthrough potential of AIに関するセッションについては大変参考になりました。
簡単にまとめますと、
・急いでLightweightなアプリケーションを作るべきではない。利用者のニーズをよく考えて、会社の長期戦略を考えることが重要です。
・fine tuningレイヤー追加しなくても基本モデルでも十分機能する。トレーニングデータを増やすより機能を考えることが重要です。
・まず行動することは大事。やっているうちに戦略が見えてくる。

以下は自分の日本語訳になります。

数年前に似た障害があったが、
ANAシステム障害 顧客DB同期処理失敗?
ANAシステム障害 顧客DB同期処理失敗? その2
今回は別の原因がらしい。

4月3日に発生した国内線システム不具合の原因及び再発防止策について

4月3日に発生したシステム不具合により、多数の国内線に欠航・遅延を生じさせる結果となりました。ご利用のお客様、関係の皆様に多大なご迷惑をお掛けいたしましたこと、深くお詫び申し上げます。

この度の不具合につきまして調査を行った結果、原因が明らかになりましたので、再発防止策とあわせてご報告申し上げます。

発生原因
国内線旅客システムのデータベースにおける、ソフトウェア不具合であることが判明しました。具体的には、予約管理業務のために、特定のデータを抽出する日常の処理において、ソフトウェアのバグを起因とするエラーが発生し、データベースサーバー2台が一時的に高負荷状態となりました。その結果、データ処理が滞り、サーバー2台が同時停止しました。

再発防止に向けた対応
(1)データ抽出方法の変更

(2)データベースサーバーが2台同時に停止しないための制御プログラムの強化

上記を確実に実施した上で、万が一、今後システム障害が発生した場合に備え、バックアップシステムへの迅速な切りかえ、訓練の実施などの対策を講じるべく、引き続き対応を図ってまいります。

ChatGPT

SNS上はこの半年間ChagGPTが一番の話題に間違いない。
これは自然言語処理の革命である。
今後の10年は、GPTによる技術革新とイノベーションを大いに期待したい。

金曜日に会社に行って同僚とAIとGPTについて雑談した。
私の見解は、100年前に比べて一般的な人々は週末がなく、毎日十数時間働いていたとして、
大量生産の工業化とIT化により週5日、1日8時間の労働が標準となった。
なので、AI化が進んだ結果、週末に3日間休みを持ち、1日6時間の労働が新しい常態になるでしょうと思う。

輻輳考

先週末からAUのシステム障害で輻輳が流行語になっていたようで、「輻輳」とは何か調べてみました。

まずは、「輻」。Wikipediaによれば、

スポーク(spoke)とは、輻(や)とも呼ばれる、車輪を構成する部材のひとつである。 中心から放射状に伸びる棒状部品がスポーク。 外周部分を支えているリムと、車輪の中心にあるハブをつなぐ。基本的にはハブから放射状に伸びている。

「輳」は、mojinaviによれば、

輳とは、あつまる/車の輻が轂に集まるなどの意味をもつ漢字。

「輻輳」のWikipediaの解説は下記となります。

輻輳(ふくそう)とは、物が1か所に集中し混雑する様態をいう。

DPEが最近流行っているようで、関連資料をメモしてみました。

DPE(Developer Productivity Engineering)が新しいソフトウェア開発工学の方法論で、ビルド・テストとCIなどの自動化ツールにフォーカスしています。その実践をDPEチームにより担当されます。
DPEとSREの違いは、SDLCフェーズの違いであって、DEV(development & test)開発生産性とOPS(deployment & maintenance)運用信頼性の違いだと思われます。
なお、DXE(Developer Experience Engineer)はDPEを実現するためのエンジニアロールの一つと自分が解釈しています。
ちなみに、GoogleのEngineering Productivity部門にDPEやDXEとのロールがなく、通常のSoftware Engineer (SWE)とTest Engineer (TE)だけあります。

4年前に開発生産性を考えるサービス化(API化)の本質はソフトウェア開発産業化記事は、DPEのようにツールチェーンのことを意識していたが、明確的に言葉定義として出てこなかったのが残念。

DPE - Developer Productivity Engineering

1 From QA to Engineering Productivity

Google Testing Blog Tuesday, March 22, 2016

In summary, the work done by the SETs naturally progressed from supporting only product testing efforts to include supporting product development efforts as well. Their role now encompassed a much broader Engineering Productivity agenda.

2 The Effect of Work Environments on Productivity and Satisfaction of Software Engineers
Brittany Johnson, Thomas Zimmermann, Senior Member, IEEE, and Christian Bird, Member, IEEE
2019/09

3 Developer Productivity Engineering: Introduction and Key Concepts

gradle.com By Dennis Welter
September 9, 2019

Hans Dockter, CEO & Founder of Gradle, talks about the emerging practice of developer productivity engineering, a discipline of using data to improve essential development processes from build/test to CI/CD.

Topics covered in this webinar are:

Quantify the costs of a low productivity environment with wasted time waiting for builds, tests, and CI/CD pipelines
Communicate the importance of fast feedback cycles and catching errors earlier, including incorrect signals like flaky tests
Discuss acceleration technologies for speeding up feedback cycles
Make the practice of developer productivity engineering a respected discipline
Use data to understand and improve essential development processes

ビルド、テスト、CI/CDパイプラインの待ち時間にかかる無駄な時間など、生産性の低い環境におけるコストを定量化する
フィードバックサイクルを高速化し、不具合テストのような不正確なシグナルを含むエラーを早期に発見することの重要性を伝える。
フィードバックサイクルを高速化するためのアクセラレーション技術について説明します。
開発者生産性エンジニアリングの実践を尊重される規律とする
本質的な開発プロセスを理解し、改善するためにデータを使用する

デジタルオシロスコープ

1990年代半ば、ハードウェアの開発に携わっていて、デジタルオシロスコープを日常的に使われていた。
その後、HPのVXIバスとオシロスコープ、電圧計、信号発生器、そして無数のスイッチやリレーが使われるようになった。
テストプログラムは、マイクロソフト社のプログラミング言語と開発環境を使用していた。
トリガーや外部トリガー等も含め、全てのテスト工程が完全自動化されており、今考えるととても高度なことだと思う。

最近、自己満足のため波形を見るだけのおもちゃとして、OWONのSDS1022というデジタルオシロスコープを買いました。


パナソニック製ニッケル水素電池充電器からの波形、5Hz、2.5V。

Scaling Kubernetes to Over 4k Nodes and 200k Pods

PayPalはApache MesosからKubernetesへ移行しようとしていて、ただパフォーマンスチューニングでは大変苦労したことを記事にしてくれました。
Apache Mesosでは簡単に1万Nodeまでスケールアウトしましたが、Kubernetesでなかなか負荷テストが通らなかったそうです。色々やった結果は4000止まり。
ちなみに負荷テストツールはk-benchを利用していました。

テスト環境:
ーGCP
ーWorker Nodeスペック:4CPU、最大40Pod
ー規模:3つMaster Node、3つNodeのetcdクラスター、4100 Worker Node、20万Pod