3月号。やはりトレンドはKubernetesかー。
- 「結城浩の再発見の発想法」
- 「なぜ、Kubernetesを使うのか?」
- そういえば使い道どうしようかなと思っているThinkCentre、Kubernetes実験台にしようかなと思った。
- コンテナ活用の課題。デプロイ管理の複雑さ、管理/連携/運用のコスト、コンテナイメージの容量や運用コスト、障害発生時の判断対応、通信対応。
- 「コンテナ・オーケストレーションツール扱いはあまりされませんが、『AWS ECS』など」そうかー…
- etcd, control plane, workerのノードで構成。YAMLで書いたマニフェストをインストールし、クラスタでコンテナを起動する。「あるべき状態」を定義してKubernetesが自動的に実現・維持を行う宣言的API。
- 依存関係のある複数のコンテナが1つのPodという単位で実行される。Podは同じノードでまとめて実行され、IPアドレスはPod単位で割り当てられる。Pod内ではコンテナ間通信・ボリューム共有ができる。
- サービスディスカバリとロードバランシング、ストレージオーケストレーション、自動化されたロールアウト/ロールバック、自己回復、自動ビンパッキング、秘密情報と設定管理。
- ストレージ共用のためのCSI (Container Storage Interface)が最近導入されている。
- Kubernetesのリリースサイクルに合わせると、4ヶ月に1度、あるいは14ヶ月に1度のアップグレードサイクルが必要になる。
- The Twelve-Factor Appの原則。中でも「アプリケーションをステートレスなプロセスとして実行」「高速な起動とグレースフルなシャットダウン」「ログは標準出力・標準エラーに出力」。
- Serviceリソースを使うことで複数箇所の整合性を1つのリソースとして管理できる。たとえばPodのIPアドレスに依存しないClusterIPや、DNSレコード。Serviceと同時にEndpointリソースが作成され、Podが増えたときにバランスされる。
- 「ITエンジニアスキルアッププログラム」
- 1つめ記事は豆蔵のIT研修方面の方による、キャリアプランの組み立て方の話。
- キャリアを真剣に考える。急に迫られて焦らないようにする、景気やChatGPTなど外部環境の変化への対応。
- キャリアアップの道筋をつける。目的、方向性、働き方を明確にする。スキルを考える。
- 目標を立てる。将来のあり方の具体化、必要要素の抽出、目標記述化、日々のタスクやスケジュール化、実施と定期評価。
- モチベーションを維持する。
- 2つめ記事はjnchitoさん。『プロを目指す人のためのRuby入門』、まだ積んでいて申しわけない…。
- 3つめの記事は、はてな社のid:taraoさんだった。
- 「パーソナルスキル」「ソフトスキル」と言われるような領域が、チームのソフトウェアエンジニアとしてうまく仕事をするために重要ではないか、という提起。
- タスク管理力。サブタスクに分解し、技術領域の違い、相談議論熟考の有無、自己完結か他者作業を要するかでさらに分類。
- プロセス管理力。リソース効率（メンバーそれぞれに別々にプロジェクトを割り振って稼働率を上げる）よりもフロー効率（各タスクを片付けて1つのプロジェクトの開始〜完了のリードタイムを最小化）。継続的運用するプロダクトでは運用期間が長いほうが価値の総量は増える＝早く完成させたほうが有利。複数人作業でのリードタイムを短縮するには、クリティカルパスに注目して並行作業をスケジューリング。
- 目的意識力。「何のために」→「何を」→「どうやって」で捉える。
- 育成力。コーチング。アクティブリスニングとオープンクエスチョン。Iメッセージによるネガティブフィードバックの伝え方。
- メンタルコントロール力。やる気maxに入るまでに小さい簡単なサブタスクで始めてみる。ネガティブなときの論理療法。
- 1つめ記事は豆蔵のIT研修方面の方による、キャリアプランの組み立て方の話。
- 「先取り! C++23」
- C++もいろいろ便利になってるんだなぁと思いつつ、やはりあまりお近づきになりたくないな…という気持ちがある。今年の言語習得はGo言語で許してください。
- 「Denoで始めるサーバサイドTypeScript開発」
- 「画像生成AIのしくみ」
- 画像生成器の話。GAN、拡散モデル、VAE。
- GANの生成は精巧な画像を生成できるが、データの多様性が高いとモード崩壊の欠点が出やすい。
- 拡散モデルは多様なデータでも高品質に生成できる。GANが似た構図ばかり作るのに対し、いろいろな構図で生成する例。ノイズが付加された画像からノイズを除去する逆拡散過程。ノイズ推定のニューラルネットワークとしてU-NetやTransformers。テキストをエンコードしたベクトルを渡すとtext-to-image、画像をエンコードしたベクトルを渡すとimage-to-image。推論の回数倍だけの時間がかかる。
- 潜在拡散モデル。Stable Diffusionが採用しているもの。ピクセル空間ではんく圧縮された潜在空間で拡散モデルを扱う。VAEで空間の間を行き来するネットワークが必要にはなるが、推論回数の計算量を削減できる。ほかにも繰り返しの間引き、逆拡散過程の数値解法なども。
- image-to-imageの可能性。
- 現在の問題点。複雑な構造や、物体の数・位置関係、複雑なクエリの一部を再現できない、といった初期の問題は対策されつつある。データセット由来の問題、バイアスの問題は根深い。
- 「three.jsでお手軽3Dプログラミング」
- 「『らしさ』の本質に迫るGo言語」
- 変数命名規則。キャメルケースを使うのが慣例。外部に公開するなら先頭大文字にするのがbest practice。HTTPなどもともと大文字のものはそのまま使う。情報に過不足ない名前にする。「変数に型名を含めないという考え方は自分のペットに『犬』や『猫』といった品種名を付けないのと同じだ」なるほど。
- 「最強の開発環境探求の道」
- 「リソースから考えるBCPの手引き」
- ITリソースの話。情報を扱う物理的な資源、サーバやネットワーク機器、PC端末など。事前対策は必要だが、被害を受けても物理的な代替準備は可能。BCPの発動判断基準が必要。再構築の際にはインシデント対応フローで再発防止策。
- 「AWS活用ジャーニー」
- みんな大好きLambdaのお話。FaaSに分類されるクラウドサービス。関数をデプロイし直接実行する、サーバレスコンピューティング。
- 事前に用意された言語たちのマネージドランタイム、独自に実装できるカスタムランタイム、Dockerコンテナを利用するコンテナイメージ。最新ランタイムを使うのがよい。
- メモリ量を指定して実行する。Graviton2だと低コスト・高パフォーマンスでおいしい。Compute Optmizerを使うと利用状況に基づく推奨事項提案をしてくれる。適切に使ってコスト最適化する必要。
- デフォルト3秒〜最大15分のタイムアウト設定（一部は15秒〜）。そういえば社内でこのあたりの罠の話があったなぁ。待ち時間も課金されるため、マルチスレッドや関数分割などを駆使する。
- 1,000まで同時実行できるが、相手API側でスロットリングされる懸念あり。必要に応じて実行予約で数を制限する。
- マネージドVPCで動作。利用者のEC2/RDS等リソースには通常ではアクセスできず、設定でHyperlane ENIリソースを有効化してユーザーVPCのENIと接続して使う。
- イベント駆動アーキテクチャと好相性。同期呼び出し（SQS/DynamoDBなど）と非同期呼び出し（イベントキューを使う。S3/SNSなど）。非同期の場合は成功可否を送信先で設定（SNSトピック/SQSキュー/Lambda/EventBridgeイベントバス）。
- イベントソースマッピング＝サービス(イベントソース)-Lambda(イベントハンドラ)をつなぐリソース。DynamoDB/SQS/Kinesis/MQ/MSK/Apache Kafka。
- LambdaをWeb APIとするときの公開エンドポイントURLの作成は、API Gatewayか、関数URL。公開範囲には注意。
- 「Ansible 現場を支えるPlaybook」
- 「魅惑の自作シェルの世界」
- 複合コマンドやパイプラインの紹介と実装。だんだんそれっぽくなってきた感じ。
- 「Pythonでネットワーク自由自在」
- ヤマハRTX830のnetmiko経由での操作。
- 「エンジニアも知っておきたい法律知識」
- みんな大好きな商法512条の話。契約書ないまま打ち合わせで詳細詰めて、要件定義レベルを超えて実質作業を始めたのに中止になったときに支払いを求められるかどうか、というやつですね。なお（connection disconnected）
次回はCPUのしくみか。ラムダノートさんへの対抗だな！
