メモ置き場

作成日時：2024-12-02
更新日時：2024-12-02

メモ置き場。見出しもばらばら。
いつかまとめる。

・作業をするなら目的を定めろ
→何がしたいのか
　負荷試験をするならどういったデータを作ってどう登録し、どういう指標を取るのか。

・コーディング規約 / コードレビュー / 設計書
→設計書が無いと属人化を招く。実装者にしか分からんから。
　設計書が無くてもコードを見ればいいが規約やレビューがなされていなければ可読性が低い。

情報連携
チームへの外部打合せ内容の展開は絶対。

format-hex
Wai-aria
自己文書化
ssh+keyscan
ssh、パスワード無くても認証行ける件
サクラエディタ重複排除⇒選択してからAlt + M
springメッセージ変更はプロファイル
- デフォルトに全部定義してプロファイルに差分
- デフォルトにフォールバックするにはpropertyに定義
JUnit、カバレッジはデフォルトで見られる
LBでHSTS
IDまたはPW
F5は実質的なキャッシュ確認には使えない
- 少なくともページは必ず取りに行っている
Markdownこそパラグラフライティング
真っ先にコストの話をする
- マネージャーや顧客はそこに重きを置いているだろうから
追跡可能性のあるログ
根本原因分析
- 何故それが必要か
Webアプリってプレゼンテーション基盤がブラウザだから、そこのメンテしなくてよくて楽だよね

概念への名づけは脳内インデックスの付与行為

書き手を想像してメンタルモデルを切り替えろ。
Linux向けならLinux向けにビルドするが如く。

タスクの依存関係

ファインマンテクニック

説明する人がいないならば、脳内の自分に対して説明する。
ある意味、アクティブラーニングの最下層「人に教える」を行っていると言える。

CQRS
イベントソーシングとTime Series Databases

ストラングラーパターン
システム移行戦略「レガシーミミックパターン」＆「ストラングラーフィグパターン」とは？ - Qiita

クラウドのコントローラー

サービスを管理する奴。

IaaS:OpenStack
Pass:CloudFoundary

インフラ

基本的に機能はどこのサーバーに置いてもいい。

SSL終端
プロキシ
WAF
LB

SSL終端をLBにやらせたりサーバーにやらせたり。
WAFに金がかかるならWEBサーバーに入れれば？ModSecurityとか

YAMLにタブを使うな

仮想化

ホスト型⇒ハイパーバイザ⇒Docker⇒wasm⇒wasm cloud。

ホスト型：ホストOS上の仮想化ソフト上に仮想OS
ハイパーバイザ：ハイパーバイザ上に仮想OS
Docker：コンテナエンジンの上にコンテナ

WASMを実行するためのランタイム、wasmCloudがCNCFのサンドボックスに | Think IT（シンクイット）

ProxyによるIPの隠蔽

Design Doc

何を何のために、どのように作るか。
システム開発をするにあたっての、大まかな概要。
- 詳細な情報はソースとか設計書を見ろというスタンス
テンプレート/フォーマット/内容は自由。
- BOSCARとADRを含んでもよろし

フォーマット案

とりあえず自分が書くのならば、下記の感じ。
減らしても、増やしてもよい。

システム名称
目的(Objective)
背景(Background)
やるやら(Scope)
制約条件(Constraint)
前提条件(Assumption)
成果物(Report)
システム構成図
- ADRまたは代替案を提示し、何故そうしなかったかを記載
- 言語とか技術とか
各サブシステムの説明
ドメイン的な話
- 用語集
- 特殊なフロー
ゴール条件(終了条件)
マイルストーン
参考文献
変更履歴

システム化の対象

クラスもテーブルもヒト・モノ・コトを表せ

みずほ

フェールセーフ
RCAの重要性
Sysmfowareの謎仕様
- インデックスをメモリに置く際の上限
SOA / ESB
みずほの体制
- 事なかれ主義
- 言うべきことを言わず、いわれたことしかやらない

クレジットカード

CARDNET
CAFIS

npm脆弱性確認

npm audit
npm audit fix

RAID10とRAID01

01:ストライピングしてミラーリング
10:ミラーリングしてストライピング

ストライピングは片方が壊れたら終了。
01はRAID0構成部が1台でも死んだら終了。
10はRAID1構成部が2台とも死んだら終了。

「RAID01」と「RAID10」の違い｜「分かりそう」で「分からない」でも「分かった」気になれるIT用語辞典

ベクトル化

同じ操作を一度に複数の要素に適用するCPUの機能。SIMD。
PythonのNumPyとか。

JavaならばJVMが勝手にやってくれたり、JNIやVector APIなどがある。
Vector APIはまだ正式化されていない。
Java 22新機能まとめ #OpenJDK - Qiita

高負荷回避

DB

別のDBなどに保存して、後で反映。

Redis：速い
NoSQL：高負荷得意
Queue

AP

制限設けて429を返すとか。

vscodeでサーバ起動できる

FURPS+

複数台サーバー
スティッキーセッションかredisまたはdb。

MQのbrokerを分散させたのがApache Kafkaという認識。

フロントで画像圧縮
エッジでも。

静的サイトにおけるCSRF

サーバー側でcookieに書き込むか、JSでtoken取得用API叩く。

外部アクセスは遅くなる

過剰なマイクロサービスはオーバーヘッドが大きい
DB：やり取り/データ量を小さくすべき
WEB<=>APもオーバーヘッド

多少おそくなってもやりたいことがあるならば、それをすべき。
クラウドならコストかかりそうだけど。

障害の局所化
(機能としての)役割分担
最小権限
スケールアップ/ダウン

確認する

レスポンスヘッダの確認
- レスポンスは圧縮してるか
- キャッシュ系
セキュリティ
- CSRF
- CSP
- XSS
- iframe
js検索したらtoken入ってないか
検索
- ページング遅くないか
- 最後のページを表示する場合など
- インデックスは使ってそうか
絵文字、特殊文字(文字数カウントとか)、外字
ダウンロードファイル内容

パフォーマンス

「小は美なり」

APログの抑制
- ディスクI/Oが発生する
- 追跡可能な最小限のログを出す
DBのチューニング
- コネクションプールの設定は最適化
キャッシュの採用
- セキュリティに注意。他人のデータを表示しかねない。
- 静的データのキャッシュ
- APレベルでのキャッシュ
アーキテクト
- サーバーレスが安いかもね
- Lambda + S3+ Amazon Aurora Serverless
ソースの見直し
- 下記をなくす
  - 無駄なDBアクセス
  - 無駄なディスクI/O
  - N + 1
  - 可読性を下げる無駄なラムダ
  - コーディング原則無視
レスポンスの圧縮

マルチテナント

1システム1会社から、1システムで複数会社をまとめる。
クラウドの資産は減らせる。
セキュリティ関連の被害を局所化できる。
DBへのレコード追加により、無停止で会社を追加できる。
懸念点は多い。

データ量の増大
- パフォーマンス悪化
- バックアップ時間の増大
アクセス量の増大
セキュリティ
- 他の会社のデータが見られてしまったり
メンテスケジュールのすり合わせ
障害対応
個社対応のやりかた
- フィーチャーフラグ
ログインユーザの一意性

DBのセキュリティに関しては、RLSでDBユーザごとに参照する行を制限するのもいいが
パフォーマンスは低下するし、設定ミスをしたらまずい。

CDNにおける圧縮ファイルの供給

(AWS CloudFront) 圧縮ファイルの供給
 CDNでWEB高速化コンテンツ圧縮（gzip）の設定と注意点

転送量の削減により、料金の節約と表示スピードの改善が出来る。
CloudFrontはデフォルトで設定がOFFらしいので設定すべき。

protocol buffers

gRPCで使われたりする。
スキーマ(構造)言語。

定義からソース出せたりする。
定義を元にJSONやByte吐いたり出来る。
ByteをDBに突っ込んだり
型安全
いろんな言語対応。JavaScriptも。
gRPC以外に使ってもよい

EXCEL

エクセルでワイルドカード使える

VLOOKUP

取得する値が空白の場合、“0”が返却されるので、それが嫌ならば

=VLOOKUP()&""

で空白に変換できる。

フィーチャーフラグとアクセス制御

権限やデプロイ先に応じて処理の有効無効を切り替えるのは、フィーチャーフラグではない。
ただの機能制御。

フィーチャートグル

複数のソースコードのブランチ（機能ブランチ）を維持するのとは別の方法を提供しようとする手法

新機能の段階的なロールアウト
A/Bテスト
実験的な機能の制御
特定の環境や状況での機能の有効/無効の切り替え

トランクベース開発などで、ブランチの複雑性の解消やビックバンリリースの回避をしたりするときに使う。
開発が終わっていないものをリリースできたりする。()

BFF

ある意味Facadeパターンだよね。

キャッシュスタンピード/ドッグパイル

キャッシュが切れた時、オリジンへ大量のアクセスが発生すること。

対策

事前に再生成
取得のシングルトン。ロック掛けて順番に再生成。

ZOZOTOWNリニューアルで実施したCache Stampede対策 - ZOZO TECH BLOG

カスケード障害

システムの一部で発生した障害が連鎖的に波及し、システム全体に影響を及ぼす現象を指す。
2021年のみずほ銀行みたいなやつ。

サーキットブレーカー

障害発生時にタイムアウトまで待たせず、即遮断する。

RASIS - Wikipedia

タイムアウト

タイムアウトしても処理は続く。
クライアントに返しただけで、バックは継続。

ログ出力

当然ながら大量に書き込むとパフォーマンスは低下する。
しかもそれが並列プロセスから書き込みされるならば、1時間単位で処理が遅くなったりする。
書き込み待ちとかで。

検索結果が多すぎて応答が遅い場合

下記の方法がある。

一般的なページング。ページリンクを押したら、オフセット使用して取得する。
検索結果を既定の件数で打ち切り、それ以降の情報が欲しければ、検索条件を指定するように促す。
1. 規定件数 + 1でLIMITして、件数 = 規定件数 + 1ならば、超えているという判定。
検索条件を必須にする。

VBA小ネタ

自作関数を呼んだセルを取得する

Set callerRange = Application.Caller
rowNum = callerRange.Row
colNum = callerRange.Column

自作関数で#N/Aを返す

CVErr(xlErrNA)

MQTT-QoS

QoS 0. 最大1回
QoS 1. 最低1回
QoS 2. 1回

EDNS0

UDPが512バイトまでではなく、4096まで可能になった。
CDNにおける最適なCDNエッジを返却。

金融

勘定系　定期性　流動性
使える文字は事前に確認しておく
- 拗音とか

httponly
secure
samesite
domain

CORS

CORSはAPI直たたきには効果ない

セキュリティ

CSPで不正なスクリプトの実行を阻止
CORSで外部からの不正なアクセスを防ぐ
CSRFトークンで正しい画面から送信されたことを確認
リファラチェックで正しいドメインから送られたことを確認
Authorizationヘッダを見て認証済みかを判断
Cookieは適切に
アプリ側でデータへのアクセス権限があるかを確認

ペッパー

別の所においてあるソルト。
シークレットソルトともいう。

TailwindとかCSSらへん

ユーティリティーファーストとTailwind CSSのススメ #React - Qiita

コンポーネントの思想があってこそ生きる。
それが無いならば面倒くさすぎる。
@applyでもいいけどさ。

AIと相性良いらしい。

こだわりなければ、MUIとかVuetifyとかが手っ取り早いか。
業務系とかは。

CSS Modulesもいいなと思った。

ReactにおけるCSSの利用はどうしたら？自分なりに結論出してみた
 CSS設計思想の振り返りと今について考察してみる - ELW株式会社テックブログ

DB：個人情報を全部暗号化

まあやったほうがいいっちゃあいいけど。
復号にコストが掛かる。
RDSとかデフォで暗号化されているし。

要件とか法規制とかでやることもある。

アーキテクチャ

様々な物に触れる
ドメイン知識

ソフトウェアアーキテクチャの基礎

ソフトウェアアーキテクチャの第一法則
ソフトウェアアーキテクチャはトレードオフがすべてだ。
ソフトウェアアーキテクチャの第二法則
「どうやって」よりも「なぜ」の方がずっと重要だ。
Mark Richards, Neal Ford. ソフトウェアアーキテクチャの基礎: エンジニアリングに基づく体系的アプローチ. 島田浩二訳. 19-20.

【WIP】アーキテクチャ特性

品質特性。

P.60

アーキテクチャスタイルスタイル

アーキテクチャの一覧。
アーキテクチャはそれぞれ組み合わせることができる。

レイヤードアーキテクチャ
- MVC
- Spring Boot
  - モジュラモノリスなSpringもある
  - Spring Modulithで始めるモジュラモノリス開発 - Speaker Deck
パイプラインアーキテクチャ
- Apache Kafka
マイクロカーネルアーキテクチャ
- Eclipse、決済
サービスベースアーキテクチャ
- モノリスとマイクロの中間
- サービスごとの分離。マイクロよりは緩い分割。
- DBは1つ、またはサービス単位なので、トランザクション管理が容易。
  - DB間の整合性を気にしなくてもよい(DBを跨がないならば)
- 「管理者サイトとユーザサイトで分けた」というのは分散モノリスっぽい
イベント駆動アーキテクチャ
- MQ
- ブローカートポロジーとメディエータートポロジーがある。
  - 前者は処理の順番を制御できない、後者は出来るが速度が下がる
スペースベースアーキテクチャ
- 高負荷環境
- 処理ユニットでデータキャッシュを共有し、DBにはキューか何かで非同期で更新、取得。
サービス指向アーキテクチャ
- ESB、SOA
マイクロサービスアーキテクチャ
- 細かい分割。各サービスがDBを持つ。
- コレオグラフィ/オーケストレーション
- サイドカーコンテナ
  - サービスメッシュにおいて、メインコンテナのプロキシとなる。
  - ロギングやメトリクス収集、SSL終端などを代わりに行い、メインの負荷を軽減。
  - 別Podに転送したり。
  - 参考：Software Design 2024年7月号連載「レガシーシステム攻略のプロセス」第3回 API Gatewayとサービスメッシュによるリクエスト制御 - ZOZO TECH BLOG
  - 参考：istio

simple is bestなので、レイヤードでいい。
それ以外は、レイヤードでは解決できない問題がある/起こりうる場合になってから考える。
データストアでいきなりNoSQLを選択しないが如く。

分散系のアーキテクチャは、レイテンシがあるし、トランザクション管理が面倒くさい。
クラウドの場合、サービス間の通信に対してコストが掛かる。

参考：DMMはAWS“から”オンプレミス“に”切り替える　サーバーとネットワークのコストから見直す適切な環境選び | ログミーBusiness

デプロイ容易性
そのサービスに適した技術で実装できる
- 一枚岩だと他サービスの内容が、技術選定に影響を与える。
作業分担できる

変更しやすい体制を

考えたアーキテクチャが正解である保障は無いし、そもそも正解はない。
だからこそ変更しやすい体制が無ければならない。
ADR、自動テスト、ドキュメント、キレイなソースは必須。
これらは変更する勇気を与える。

キューによる疎結合

モジュラモノリス

単一のデプロイ単位
内部的なモジュール性
単一プロセスでの実行

サービスごとにjarを作成し、それらをまとめてwarにしている場合はモジュラモノリスと言える。

1サーバに複数コンテナを建て、それらを協調させて1つのアプリケーションにするのは、
厳密にはモジュラモノリスでは無いが、それの精神性を持っている。

早期リターン

ガード節と同じ。
リクエストを受け取ったらすぐレスポンスを返し、裏で処理を実行する。
非同期。

キューってDBでも出来るよね

定期的にポーリングする感じで。

サーガパターン

分散環境におけるトランザクション管理。
処理に失敗した際、関連する更新を戻す。(補償トランザクション)
下記の2パターン。

仮登録⇒本登録
本登録⇒取消登録

ADR

書け。
「何故」が分からなければ正当な実装は出来ない。
アーキテクチャの変更の妥当性も検証できない。

書くことによって、思考を整理できるかもしれん。

AI

文書として残せば、MCP経由でAIに読み込ませて質問できる。
また、エージェント系のAIにコーディングしてもらう際も、
ADRはその成果物の品質を上げることに役立つ。

弾力性(だんりょくせい)

スパイクアクセスに耐えられる力

ドメインの理解

キーパーソン
ヒアリング
アンケート

アーキテクトの流れ

方針
現状分析
問題点分析
解決策決定
- 全部システム化する必要はない
- 運用で回避でもいい
システム化対象の決定
機能要件/非機能要件/データ洗い出し

優先順位の概念

アナロジー思考

分散系は「小さくする」事で、変更容易性やデプロイ容易性を得た。
これはコーディングでも同じ。SOLIDやDDDとかも。
ある考え方は他の領域にも使える。

ログに個人情報を載せるな

法律チェックリスト

個人情報保護法
電子帳簿保存法
改正民法632-656
- 善管注意義務
- プロジェクト管理義務
クレジットの3Dセキュア

体制は疑問提起から生まれる

「じゃあこうしよう」が具体化されたものが体制。

言語こそPJで一番曖昧性を持つ

文章から如何に曖昧性を除去できるか。
「何を言っているか」を考えるリソースを創造的な思考に使わせる。
その為に、明確な意思疎通が必要。

「何故」を説明する。
同意と共通認識を得る。

形容詞と副詞を排除し、定量的に伝える。

正しさは文脈に依存する

だからBOSCARとADR

未知の未知とアジャイル

早く失敗することで「未知の未知」を知る。