読書まとめ on yyh-gl's Tech Blog

『暗号解読（上）』を読んで

Fri, 24 Jan 2025 00:30:40 +0900

はじめに

『暗号解読（上）』を読んだ感想を簡単にメモしておく。
なお、本記事は自分で書いた読書メモをChatGPTに整形してもらったもの。
（文章としておかしい部分だけ自分で修正）

読書メモ

ソフトウェアエンジニアとして情報セキュリティの知識を深める目的で、サイモン・シン氏の著書『暗号解読（上）』を拝読いたしました。
本書は暗号の歴史から具体的な解読手法、さらには現代の暗号理論に至るまで幅広く取り上げており、暗号に関わる者として学ぶところが多くありました。
以下に、本書を通じて特に印象に残った点を整理します。

1. 暗号システムの本質

どれほど強固な暗号方式を用いていても、鍵が漏洩すればすべてが水泡に帰すという原則は改めて肝に銘じるべき事項です。

2. ヌル文字の歴史的背景

「ヌル文字」といえばプログラマにはおなじみですが、実は16世紀にすでに「何の意味も持たないダミー文字」として暗号の世界で使われていたそうです。歴史の長さに驚き。

3. 弱い暗号の危険性

「弱い暗号を使うぐらいなら、最初から暗号など使わない方がましだ」という指摘は極めて重要です。暗号への過信は、平文なら絶対書かない内容までつい書いてしまうリスクを孕みます。セキュリティ意識の啓発においては、強固な暗号方式の採用だけでなく、その危うさを十分に理解してもらう必要があります。

4. 古典的な解読テクニック

頻度分析
連接特徴
- 例として、英語では「q」の後に必ず「u」が続く等、文字の連鎖関係を用いた分析があります。

こうしたテクニックは一見地道ですが、歴史上多くの暗号がこれらの手法によって解読されてきました。情報理論や機械学習が普及する現代でも、基本となる考え方を学ぶ意義は大きいと感じます。

5. ワンタイム・パッドの特異性

一度きりの使い捨て鍵を用いるワンタイム・パッドは理論上解読不可能とされています。しかし、膨大な鍵の管理が必要になるため実用的ではなく、あまり使われてこなかった。ただし、ロシア大統領とアメリカ大統領のホットラインのような特殊な用途では今なお採用されている点が非常に興味深いです。

6. エニグマと鍵交換の重要性

20世紀に登場したエニグマは極めて複雑な印象を与えますが、実際の仕組みは比較的シンプルであり、物理的にもコンパクト（34×28×15cm・12kg）であったことが紹介されています。打倒エニグマの歴史から、安全な鍵交換の重要性も学べます。

7. 反復は秘匿の大敵

暗号においてパターンや繰り返しは危険を伴います。同一のIV（初期化ベクトル）を使い回すといった行為が脆弱性を生むのは、まさにこの法則に通じるものがあります。暗号の設定や運用の細部にわたるまで注意が必要だと痛感させられます。

毎日決まった時間に放送される天気予報のような“当たり前”の情報でも、暗号解読のヒント（クリブ）となり得ることが紹介されています。日常に潜む定常的データが、思わぬ形で暗号解読に利用される様は、現代の情報漏洩リスクにも通じる示唆を与えてくれます。

8. 数学には論理と直感の両方が求められる

本書を通じて改めて印象に残ったのは、数学の問題を解くにあたっては「論理的思考」に加えて「直感」も欠かせない、という視点です。暗号の解読過程は、単なる数式の機械的処理だけではなく、数多くの仮説検証や柔軟な発想を必要とすることを本書は示唆しています。

9. アラン・チューリングという天才

エニグマの解読で中心的役割を果たしたアラン・チューリングに関する記述からは、彼の卓越した才能がいかに戦争の行方を左右したかが窺えます。計算機科学の父とも称されるチューリングの偉大さを再認識し、その業績を学ぶことは、現代のソフトウェアエンジニアにとっても大きな意義があると感じます。

10. 解読しても公表しない情報戦

暗号を解読しても、あえて公表せず、相手に使い続けさせるという情報戦略があることも興味深い点です。セキュリティ技術は単なる防御策ではなく、攻撃・解析そして情報操作といった多面的な視点が求められます。

総括

『暗号解読（上）』は暗号の歴史的背景、具体的な解読技術、そして現代のセキュリティに通じる核心的な部分まで網羅的に扱っており、暗号に携わるエンジニアにとって大いに参考になる一冊です。数学が中心的な役割を果たす分野であるにもかかわらず、通史としても非常に読み応えがあるため、セキュリティ技術への関心だけでなく、歴史や論理パズルに興味がある方にも大変おすすめできます。

私自身、改めて鍵管理の重要性や暗号方式の運用上の落とし穴を再認識しました。本書を通じて、暗号技術はあくまで“手段”であり、それをいかに適切に設計・運用するかが要であると痛感します。今後もセキュリティへの関心を高めつつ、情報保護に対する責任と慎重さを持って業務にあたっていきたいと思います。

『データ指向アプリケーションデザイン』を読んで

Thu, 09 Jan 2025 21:40:02 +0900

はじめに

『データ指向アプリケーションデザイン ―信頼性、拡張性、保守性の高い分散システム設計の原理』を読んだ。

会社で輪読会をして、全部読みきった。

期待以上の良書に出会った感動をそのまま殴り書いているだけ。
とりとめもない文章なので、得られる知見はないと思うけど、感動を共有したいので書いた。

感想

心の底から読んでよかったと思える一冊だった。

シンプルなリレーショナルデータベースの話だけでなく、NoSQLや分散ストレージ、ストリーム処理（Kafkaとか）など、データベースに関する話が幅広く書かれている。
データ構造の話（log-structuredやBツリー）やトランザクションの話もすごいおもしろかった。

難しい話も多いけど、ふわっとしていた理解がだいぶ具体化された。
これまで何気なく使っていたデータベース。裏側のロジックを知ることで実際の開発でもいろいろ考慮できるようになった。

データベースに関するおすすめの本を聞かれたら、絶対にこの本を薦める。
（初心者におすすめする本ではないと思う）

具体的にどういったことが書かれているかは、他の人が書いている記事がたくさんあるので、そちらを参照のこと。
というかぜひ本書を手にとっていただきたい。

評価の高い本だったので、読む前から期待はしていたものの良い意味で裏切られた。
学びが多く、本当に感動したので、この記事をなぐり書きしておく。

k8s関連書籍をいろいろ読んだ

Tue, 21 May 2024 09:39:53 +0900

今回読んだ本

業務でk8sを触る機会があり、事前に知識をつけるためにいくつかの本を読んだ。
以下が今回読んだ本。

入門 Kubernetes

本書はk8sを触るうえで知っておくべき基本的な内容が書かれている。
コマンド例も書いてあるので、実際に手を動かしながら、k8sの基本について学ぶことができる。

私は趣味の開発でk8sクラスターを運用しているので、基本的には復習的な意味合いで読んだ。
とはいえ、永続化周りの知識はなんとなくでやっていたので知見が深まった。

特にk8sを初めて触る人におすすめの一冊だと思った。

注意点としては、原書は第3版まで出ており、いくつか加筆がある。
日本語版は加筆部分がないので、最新の情報を知りたい場合は原書を読むことをおすすめする。

Googleのソフトウェアエンジニアリング ―持続可能なプログラミングを支える技術、文化、プロセス

25章『サービスとしてのコンピュート』を読んだ。

k8sそのものの話はあまりない。
「コンピュート（プログラムを実際に実行するのに必要な計算能力）」というワードを中心に、スケールする環境でプログラムを動かすことの大変さと、その大変さを解消するために考えるべきことを深ぼっていく。

この話の中で、 k8sの前身であるBorgの話が出てくる。
こういった考えのもとBorgが生まれたんだなというのがよくわかった。

特に以下2点が私にとっては有益な情報だった。

スケールする環境における「コンピュート」関連の課題
『ペット対家畜』の話

コンテナセキュリティコンテナ化されたアプリケーションを保護する要素技術

k8sのための本というわけではないが、コンテナ技術の上に成り立つk8sを触るうえで知っておくと役に立つ内容が書かれている。

僕はこれまでコンテナ技術を触ってきたにも関わらず、「Linuxの機能を使って実現されているんだよなぁ」という抽象的な理解しかしていなかった。

本書を読むことで、コンテナ技術がLinuxのどういった機能によって実現されているかをきちんと理解できた。
そして、上記の話をベースに、タイトルにもあるセキュリティの話へと繋がっていく。

僕自身、コンテナセキュリティについては、頑張ってキャッチアップしているつもりだった。
しかし、ベースとなるコンテナ技術について学んだ後だと、また違った角度からセキュリティについて再考できた。

すでに実務で困らない程度にはコンテナをさわれるという方に、ぜひとも読んでほしい一冊だと思った。

【エリック・エヴァンスのドメイン駆動設計】DDD入門 Part 1

Tue, 11 Jun 2019 09:00:00 +0900

DDD の勉強始めます

新卒研修を受ける中で DDD が出てきて、勉強したくなったので、
『エリック・エヴァンスのドメイン駆動設計』（エリック・エヴァンス著，今関剛監訳，和智右桂、牧野祐子訳）を読んでいこうと思います。

今回は第1部「ドメインモデルを機能させる」の 1章と 2章をまとめます。

注意：僕の理解をそのままメモとして書き連ねていきます。
したがって、誤った理解もあると思うので、そのときはDMとかでご指摘お願いします！

1章知識をかみ砕く

ソフトウェアを作るときに、はじめから対象を十分に理解している開発者などいない。

対象＝これから作るソフトウェアで実現する作業＝ドメイン

したがって、対象について詳しい人（ドメインエキスパート）と開発者で
十分に話し合って理解を深めることが重要である。

理解したことはモデルとして書き出す。
そして、ドメインエキスパートは足りないところがあれば追加で説明する。
開発者は分からないところがあれば質問する。

上記工程を何度も繰り返し、その都度得た知識をモデルに落とし込んでいく。
→ 継続的学習（継続的学習は開発が始まった後でも行う）

はじめから対象を如実に表したモデルを作れることは滅多にない。

ドメインエキスパートと開発者では見ている視点が違うので少し話を聞いたぐらいで
完璧なモデルを作ることができないのは当たり前である。

だからこそ、対話を通して、互いに疑問点や不要な点を洗い出し、洗練する必要がある。
これが知識のかみ砕きである。

1章まとめ

ドメインエキスパートと開発者が話し合ってドメインをモデルに落とし込んでいく
- 用語の説明や不足点の追加などとにかく話す
- ドメイン：ソフトウェア化する対象（業務やサービスなど、ソフトウェア化の対象となりうる万物）
一発で完璧なモデリングはできないから、継続的に改善していく

2章コミュニケーションと言語の使い方

ドメインエキスパートが使う専門用語を開発者は理解できないし、
開発者が使う専門用語をドメインエキスパートは理解できない。

ドメインエキスパートと開発者の両者が同じ意味だと思って使っていたとしても
たいていの場合、差異がある。

このような差異があると通訳が必要となる。
通訳はコミュニケーションを鈍らせ、知識のかみ砕きを沈滞させる。

共通言語としてのモデル

通訳をなくすために、モデルを言語の骨格として使用する。

ドメインエキスパートと開発者のコミュニケーションやコード、ドキュメント、図など
全てにおいて、その言語を使用する。

【大規模サービス技術入門 5章】大規模データの処理方法についてまとめた

Mon, 10 Jun 2019 09:00:00 +0900

はじめに

社内で伊藤直也さんと田中慎司さんが書かれた

『Web開発者のための大規模サービス技術入門』を輪読しました。

今回は、僕が担当した第5回の「大規模データ処理[実践]入門」についてまとめます。

なお、本書は2010年に出版された本であるため、

少なくとも第5回の内容は今では当たり前のことという印象を受けました。

それでも、しっかりと文章で学んでおくことは大事だと思うのでまとめます。

★印は個人メモです。

以下まとめ

大量なデータを扱う場面

全文検索やデータマイニングなど RDBMSで処理できない規模のデータを

処理したい場面は多く存在します。

では、RDBMSが使えない規模のデータをどう処理すればいいでしょうか。

データを抽出

結論から言うと、RDBMSで扱うことができないデータは、適宜RDBMSから抽出して利用します。

具体的には

バッチ処理でRDBMSからデータを抽出し、

別途インデックスサーバのようなものを作って、そこに入れていきます。

★ ここで言っているインデックスサーバというのは、例えば全文検索用であれば

「検索用にチューニングした（検索しやすくした）データ構造」と考えるべきでしょう。

★ 最近は、Fluentd を使用してログを外部に吐き出してから解析したりしますよね。

それと考え方は一緒だと思います。

インデックスサーバにはRPC（Remote Procedure Call）を使ってアクセスします。

（なお、RPCと言いましたが、現在では Web API でのアクセスが一般的なので、以降、 Web API を例に使用します）

イメージとしては下図のようになります。

用途特化型のインデクシング

上述した方法を、はてな社（著者がはてな社出身の方なのでよく出てきます）では、

用途特化型インデクシングと呼ぶそうです。

用途特化型インデクシングとRDBMS

RDBMS はデータソートや統計処理、JOIN など、データに対して様々な処理を行うことができます。

しかし、汎用的故に、特定の目的だけに使うときには、それ用にチューニングしたデータ構造、

すなわち用途特化型インデクシングを使う方が圧倒的に速くなります。

★ 先ほど言っていた Fluentd を用いたログ解析システムはログ解析用にチューニングしたものと言えるでしょうか。

用途特化型インデクシングの使用例：全文検索エンジン

全文検索エンジンでは、以下3点の要求をどう満たすか考える必要があります。

【エンジニアリング組織論への招待】メンタリングの技術

Sat, 25 May 2019 09:00:00 +0900

概要

今回は、広木大地さんが書かれた『エンジニアリング組織論への招待不確実性に向き合う思考と組織のリファクタリング』という本から、

2章「メンタリングの技術」についてまとめます。

（初投稿の内容が技術系じゃなくてチームマネジメント系かよとか言わないでくださいね）

最初に覚えておいてほしいこと

メンタリングは、自律的な人材を育むために行う。

そのために、下記3点の状態にメンティ自身からなれるように導く。

自分の気がつかなかった問題に気がつくようになる
認知の歪みによる感情と問題の癒着を切り離せる
答えではなく、次の一手を生み出す行動が取れるようになる

これらがとても重要です。

以下いろいろな話が出てきますが、結局は上記3点の状態を実現するための方法です。

ここをしっかりと意識して読んでいただければ、

より一層理解が深まると思います。

以下まとめ（★マークは個人的解釈・感想です）

そもそもメンタリングとは

相手を上から押し付けるような教育方法ではない
相手の考え方を少しずつ変えることで、問題解決の力を育む手法

対話を通じて、以下の2点を行い、相手を成長させる。

歪んだ認知を補正
次の行動を促進

メンタリングと聞くと、

大学で何年も学ばないと身に着けられないような技術であると思いがちだが、

体得すればだれでもできるようになる。

エンジニアリングにおけるメンタリングの重要性

エンジニアリングは知識が全てではない

エンジニアリングでは技術的な課題がよく取り上げられるが、

技術的な課題というのは心理的な課題と密接に関係している。

例えば、

ソフトウェア開発はチームプレイ

★ 技術的な課題解決だけでなく、人間関係とかもあるってことかな

各個人の開発における問題解決は、自分自身との対話によって制御するもの

★ 自身を制すものがエラーを制す

上記のようにエンジニアリングには心理的な課題も存在する。

プロダクト開発では不確実性を排除することがとても重要である。

したがって、不確実性のひとつである心理的な課題は排除すべき対象である。

★ だから、メンタリングが重要なんですね。

メンタリングは自ら考える人材を作るためのテクニック

自立型人材と依存型人材

自ら考える人材を自立型人材、そうでない人材を依存型人材とすると、

それぞれ下記のような特徴がある。

自立型人材
- 自ら問題を発見し、解決することができる
- 問題について、自分ごととして捉えている
- 問題の根本的原因は自分にあると考える
  - 改善のために行動できる
依存型人材
- 問題を与えられてから考える
- 問題と解決策を渡されてから動ける
- 問題の根本的原因は他人にあると考える
  - 改善のために行動できず、他人のせいにしてしまう

両人材の境界線

多くの人は時には自立型人材、しかし、ある場面では依存型人材になってしまう。

それが普通である。

大事なのは、上司と部下という関係における期待値を合わせておくこと。

読書まとめ on yyh-gl's Tech Blog

『暗号解読（上）』を読んで

はじめに

読書メモ

1. 暗号システムの本質

2. ヌル文字の歴史的背景

3. 弱い暗号の危険性

4. 古典的な解読テクニック

5. ワンタイム・パッドの特異性

6. エニグマと鍵交換の重要性

7. 反復は秘匿の大敵

8. 数学には論理と直感の両方が求められる

9. アラン・チューリングという天才

10. 解読しても公表しない情報戦

総括

『データ指向アプリケーションデザイン』を読んで

はじめに

感想

k8s関連書籍をいろいろ読んだ

今回読んだ本

入門 Kubernetes

Googleのソフトウェアエンジニアリング ―持続可能なプログラミングを支える技術、文化、プロセス

コンテナセキュリティ コンテナ化されたアプリケーションを保護する要素技術

【エリック・エヴァンスのドメイン駆動設計】DDD入門 Part 1

DDD の勉強始めます

1章 知識をかみ砕く

1章 まとめ

2章 コミュニケーションと言語の使い方

共通言語としてのモデル

【大規模サービス技術入門 5章】大規模データの処理方法についてまとめた

はじめに

大量なデータを扱う場面

データを抽出

具体的には

用途特化型のインデクシング

用途特化型インデクシングとRDBMS

用途特化型インデクシングの使用例： 全文検索エンジン

【エンジニアリング組織論への招待】メンタリングの技術

概要

最初に覚えておいてほしいこと

そもそもメンタリングとは

エンジニアリングにおけるメンタリングの重要性

エンジニアリングは知識が全てではない

メンタリングは 自ら考える人材を作る ためのテクニック

自立型人材と依存型人材

両人材の境界線

コンテナセキュリティコンテナ化されたアプリケーションを保護する要素技術

1章知識をかみ砕く

1章まとめ

2章コミュニケーションと言語の使い方

用途特化型インデクシングの使用例：全文検索エンジン

メンタリングは自ら考える人材を作るためのテクニック