@hihihiroroのLog

ダラダラと。本ブログは、個人の意見であり、所属会社とは関係がありません。

202403 振り返り

気がつけばブログを出すの忘れたまま数日が経過していた。
なんだか忙しいような暇なような眠いような起きていたいような曖昧な状態で日々を過ごしている。

しかしこの状態はきっと良くないと思うので、なにか始めたいと思うけど始めるものも思いつかないのでまずは積んである本でも読むか。

べんきょうかい

特に何も。
最近成長を感じれることが無いので危機感ががが。

ほん

移動時間がへったので本を読む量も減っている。
積読をこれ以上増やすわけにはいかないのでどうにか読みすすめなくては。

えいが

ハイキューは相変わらずおもしろかった。
ちょっとずつ観ることができるようになってきているので続けて観ていきたい。

  • 劇場版ハイキュー!! ゴミ捨て場の決戦
  • ARGYLLE
  • 52ヘルツのクジラたち

ぶろぐ

デブサミで見かけた面白そうだった本についてのブログを書いてみた。

hihihiroro.hatenablog.com

「マルチクラウドネットワークの教科書」を読んだ

マルチクラウドでのデータ基盤を考えることがあったのでデータのやり取りなどでクラウド間のネットワークなどを試していたこともあり、デブサミ会場で見かけたので買ってきた。

目次は以下

Chapter 1 一般論としてのマルチクラウド
Chapter 2 「ネットワーク」から見たマルチクラウド
Chapter 3 クラウドのネットワークサービスの解説
Chapter 4 マルチクラウドネットワークのデザインパターン
Chapter 5 マルチクラウドネットワークの設計

クラウドを使ってしばらく経つし構築もいくつもすすめているがいつもいつもうまくいかない時がある。その時に問題となるのがネットワークがいまいちよく分かっていないことが原因だろうなとなることがある。そのためいつかはネットワークについてしっかりと勉強をしないといけないなと思っていたところに見かけたので読むことにした。

本書ではクラウドの歴史からマルチクラウドにする必要性についての説明がされている。クラウドのネットワークがどのようなサービスから始まり、拡大されていったかが書かれていて読み物としてChapter1、2 は面白かった。
そして、Chapter 3ではそれぞれのクラウドサービスのネットワークサービスについての解説がされていた。Azure は直接触った経験が少ないのでちゃんと理解できたとは言えないが、AWSGoogle Cloud については理解が深まったと思う。VPC についての考えや、VPC内リソースとVPC外リソースについて考える必要があり、それによって使用する場所やできることが分かれているということを考えることについて理解した。

Chapter4以降ではそれぞれの使う場所によってのデザインパターンが紹介されていた。オンプレミスとVPC間、同一クラウドVPC同士、異なるクラウド間のVPC同士、VPC とインターネット間の通信など必要となりそうな接続については一通り説明がされている。
異なる環境下での接続をする際にはそれぞれで好き勝手に設定を行っていたりするとどこかで上手くいかなくなることがあるのだろうということは容易に想像がつく。所属会社ではうまくIPアドレスの設計を行いサブネットの払い出しなどをしていただけているので、問題が少なくピアリングなどができているのだなとありがたい気持ちになった。

自分がクラウド同士の接続を試していた時に今までネットワークについてはあまり自分でいじれることがなかったということもあり失敗を繰り返してしまった。こういったネットワーク周りについてもいろいろ好き放題に試せるような環境がもらえると嬉しいなと思った。

最後に宮川さんとデブサミ会場で少しお話をした時に、マルチクラウド化することは必要だがそれらの間を本当に専用線で繋ぐ必要があるのかを考える必要があると言われてそのとおりだなと思った。何も考えずに直接のネットワークを組んでしまうことを考えてしまうが、一旦立ち止まってネットワークでは本当にだめなのかという要件を考え直すのは大事だなと。
まずは自分たちのサービスのネットワークを見直そうと。

そしてネットワーク維持れる環境提供してくれる会社や一緒に試してみましょうっていう会社などあったら一緒にお仕事させていただければと思います!

まとめ

  • クラウドの前にネットワークについて弱弱だから勉強し直そう
  • 今ある環境のネットワークについての理解などしていないのでまずは見直し
  • その後必要な箇所の修正に取り掛かっていくことにしよ

202402 振り返り

引き続きレコーディングダイエットをしている。わかってはいたけど実際につけてみると本当に食べすぎていることが多い。
そしてこれくらい大丈夫だろと思っているものがカロリーや糖質高いことがわかることが多くびっくりする。
でもせっかくなので頑張って続けてみよう。

本格的に副業をしてみたいと思っている。でも自分が何できるかわからないのでどこかでお仕事ありそうな方はぜひ話しかけていただいたり、ご飯や飲みに誘っていただければと思います。

べんきょうかい

所属会社でもTech Conference が始まりそちらの大半を見ることができた。前職もそうだが大きい会社なので、隣が何を使っているかなどわからないためとてもおもしろく見ることができた。
Platform Engineering Meetup では永瀬さんによるちいとぽの話を聞いて全く覚えてなかったので再度読もうと思った。

Platform Engineering Meetup #7
大公開!SUUMOの裏側~データ組織の取り組みLT会
PdM Days
RECRUIT TECH CONFERENCE 2024

ほん

わかっている。わかっているのだが積読本よりも新しく本を買ってしまいそちらが先に消化されていく。
時々積読の中で下の方にいる本から睨まれている気がしているのでそろそろ読みにいかなくては。

えいが

結局観に行くことがなかった。
みたいものはいくつかあるので来月はどこかで時間を取って観に行く。

ぶろぐ

今月は3連休が2回あったからか本がよく読めたなと思っている。
そのため感想も書くことが多くできて良かった。

hihihiroro.hatenablog.com

hihihiroro.hatenablog.com

link.medium.com

hihihiroro.hatenablog.com

hihihiroro.hatenablog.com

「実践データマネジメント」を読んだ

データ基盤の運用を行っているがあまり求められることを言われないので、今ってどういうことが必要なのかなと思うことが多い。見かけたので読んでみることにした。

目次は以下。

第1章 データ活用のための人と組織
第2章 データ活用のための環境整備
第3章 データ活用のためのデータ管理
第4章 データ活用を進める際の課題

最初の方はデータ基盤の作成方法やそれらの製品についつての説明などが多かった気がする。データの連携などについてはそれぞれのサービスに合わせた速度、頻度などが求められているものだと思う。別に一日1回でも困らない分析もあると思っている。事業データ側もどこか一回での閉じたデータが必要なモニタリングが必要だったりするかもしれないし、即時に連携してユーザへのレコメンドなどの精度を求めなければいけないものもあるだろう。どのようなデータが求められているかを見極めて連携をすることがまずは大事だろうなと思う。

連携されたあとのデータを使う場合に、元データまでを見にいくのは面倒なことが多いので分析基盤の近くにどのようなデータかがわかるようになっていることが大事だと思う。その際にカラムごとにどのようなデータが入ってくるものなのかをうまくデータソース管理者とうまくやりとりできる仕組みが必要だと感じている。しかし、自分の所属が今だと横断ということもあり遠いなと感じることが多くてもっと食い込んでいかないといけないなと思っている。

最後の章にあったがガバナンスを効かせるのにボトムアップなのかトップダウンなのかという話が少し書かれている。ガバナンスやセキュリティをボトムアップでやると強制力の付け方や、それぞれのやりたいところへの注力などになってしまい本当に守るべきところが守れているかわからないことが出てきてしまうと思う。そのためには一定トップダウンの強い力が必要になってくるだろうなと思う。ぜひとも偉い人たちにはこのあたりを考えてもらえると良いなと思っている。
がちがちになってしまうと使いにくくなってしまうのだろうからうまい具合のガードレールで防げるようになっていると良いんだろうな。

またデータ基盤を使ってもらうためにも、エラー率などはちゃんと出さないといけないなと思っている。SLO がなくても使ってもらえているが今後もっと利用を増やすことができるようにするためには必要だろうな。

まとめ

  • DMBOK を再度読む必要があるということを理解した
  • データマネジメントについての話は多くなかったな
  • まだまだやるべきことはありそうなのでお仕事しよう

「実務で使える メール技術の教科書」を読んだ

実は今までの社会人人生の半分はメールに係る部署で働いていたこともあり、メールの技術については少しは興味があるので読んでみることにした。

目次は以下。

第1章 メールが相手に届くまで
第2章 送受信に使われるプロトコル
第3章 メールサーバーの構築と DNS の設定
第4章 ファイルの添付と HTML メール
第5章 スパムメールを防ぐ技術
第6章 メールの暗号化と署名
第7章 メーリングリストメールマガジン

メールはいろいろ幅広い機能を使うことが多く、それぞれを調べていくととてもやりたいことを探すだけでもとても時間が掛かってしまう。たとえばメールを送るサーバについて調べようと思うとLinuxSendmail の勉強、ドメインやIP アドレス、認証情報についてでDNS 、暗号化や認証、ウイルスなどについてだとセキュリティについての勉強などが必要になる。しかし、それぞれの専門書だと詳しく書かれているがメールについての何かがどこなのかというのは分かりにくいこともある。
本書ではメールで必要になる技術について、幅広く記載がされている。ここから気になって深掘りしたくなったらそれぞれの専門書をさがしにいくことで、無駄な時間をかけずに勉強をしていけるのではないかと思う。

今は自分でメールを送る部分には関わらなくなったのであまり最新の情報を追ってはいない。でも、部署に配属されて最初に日報を送る際に telnet コマンドでメールを送る勉強をさせられたりしたおかげもあるのか、いまだに忘れてないものだなと思った。知識がいまだにあったっぽいので読み終わるのにはそれほどかかることがなかった。

最近だと2023/10 にGoogle からメール送信者のガイドライン がでたこともありメールの送り方について考えている会社が増えている気がする。そのあたりで困っている人たちの手助けなにかしながらお金稼ぐことできないかなーと思ってみたりもした。

まとめ

  • メールで使われる技術についてまとまっていて読みやすかった
  • それぞれが詳しく書かれているわけではないので気になったところはRFC などを読みにいってみたいと思う
  • メールはなくなることもないだろうから情報収集は変わらずやっていこう

「スケーラブルリアルタイムデータ分析入門」を読んだ

ずっと前に買っていたが読んでなかったので、今更ながらラムダアーキテクチャについてちゃんと読んでみようと思って読んでみた。

目次は以下。 

1章 ビッグデータを扱うための新しいパラダイム
2章 ビッグデータのためのデータモデル
3章 ビッグデータのためのデータモデル詳説
4章 バッチ層のデータストレージ
5章 バッチ層のデータストレージ詳説
6章 バッチ層
7章 バッチ層詳説
8章 バッチ層の例:アーキテクチャアルゴリズム
9章 バッチ層の例:実装
10章 サービス層
11章 サービス層詳説
12章 実時間ビュー
13章 実時間ビュー詳説
14章 キューイングとストリーム処理
15章 キューイングとストリーム処理詳説
16章 マイクロバッチストリーム処理
17章 マイクロバッチストリーム処理詳説
18章 ラムダアーキテクチャをより深く学ぶ

リアルタイムデータ連携についてはいまのところ作ることもないし、思想的なこともちゃんとみたことがなかったので読んでみたのだが、体系立てて書かれていて面白く読むことができた。

ローデータはとても大事なものとして存在しており、ローデータさえ異常がなければバッチ処理を何回やり直すことができるため、ローデータは死守する必要があることが説明されている。他にもデータが、重複なのか別データなのがわかるようにハッシュ値をつけて判別できるようにしておく。キューの仕組みを使ってのデータを更新する仕組みなども紹介されていて面白かったし参考になった。

それ以外にも集計時の概算アルゴリズムの説明や、バッチ層とサービス層、速度層のそれぞれの説明やそれぞれで使えるツールでの少しだけ具体的な説明などが書かれていてとても読みやすかった。ストレージについての話も書かれており昔のツールなどだとしても久しぶりなこともあり興味深く読むことができた。今でも使われているものもいくつかあるのでちゃんと理解をしたいなと思っている。

本書は、本当に広い範囲について詳しく書かれているなと思った。
一度読みすすめたくらいでは完全に理解できたとは言えないのでまた少したったら読んでみたいなと思っている。
その時にはカッパアーキテクチャ、その後のデータフロー、ビームモデルについてもまとめて読んでみたいなと思った。

まとめ

  • ラムダアーキテクチャの理論についての思想を読んでみた
  • 他のストリーム処理アーキテクチャとの違いを考えてみたい
  • 自分たちの基盤で必要となるものは何かと考えてはみたい

「ソフトウェアアーキテクチャメトリクス」を読んだ

トラブルが多いなとか、修正に思っているよりも時間かかると言われたりするなと思うことが増えてきたときに社内でタイトルを見かけたので読んでみることにした。

目次は以下。

1章 解き放たれた4つのキーメトリクス
2章 適応度関数テストピラミッド:アーキテクチャテストとメトリクスのためのアナロジー
3章 進化的アーキテクチャ:テスト容易性とデプロイ可能性でアーキテクチャを導く
4章 モジュール生成熟度でアーキテクチャを改善する
5章 プライベートビルドとメトリクス:DevOps 移行を乗り越えるためのツール
6章 組織のスケーリング:ソフトウェアアーキテクチャの中心的役割
7章 ソフトウェアアーキテクチャにおける計測の役割
8章 メトリクスからエンジニアリングへの進化
9章 ソフトウェアメトリクスを使用して保守性を確保する
10章 ゴール・クエスチョン・メトリクスアプローチで未知数を計測する

ソフトウェアアーキテクチャメトリクスとは本書では以下と紹介されている。

ソフトウェアアーキテクチャメトリクスとは、ソフトウェアの保守性やアーキテクチャ品質を計測し、プロセスの早い段階でアーキテクチャ負債や技術的負債の意図しない蓄積を警告するのに用いるメトリクス

p.v

1章ずつ別々のソフトウェアアーキテクトが、知っておくべきソフトウェアアーキテクチャメトリクスが紹介されている。それなので、体系的にまとまっているというわけではなく、実践者からの投稿をまとめているエッセイ集みたいになっている。

話題としてはFour Keys メトリクス、アーキテクチャ適応度関数、モジュール性成熟度指数などが紹介されていた。そしてそれらを使って組織の成熟度を測る方法やメトリクスを用いてアーキテクチャの品質向上に役立たせる方法についても記載されている。
メトリクスを定義しているだけではなく、ダッシュボードを作成し保守性を保っていくなどの話がありとても面白かった。

僕のところではまずは計測するための準備をし、計測してみる。計測できないならば計測できるようにまずは変更をしていく必要があるなと思った。
現在のうちのシステムは泥団子のものが大変たくさんあると思う。よく影響範囲やレビュー範囲を狭めるために分割したいなという話をしているが、それだけではただ単に小さい泥団子になってしまうなと。たしかに困っているのは分割されてないことではなくカオスさなので、まずはメトリクスを決めて取得し、そこから改善を考えていくのが良さそうだなと思った。

読んでいると進化的アーキテクチャでの話がたくさん出てくる。昔読んではいるけどあまり覚えてないなとなってしまったので、再度読み直してみるのが良さそうだなと思った。

まとめ

  • まずは古いシステムなので技術的負債についてのメトリクスを取ってみたいなと思う
  • これから作るシステムではメトリクスの取りやすさも考えながらレビューする
  • チーム一丸ですすんでいくためにチーム内に共有し浸透させたい
  • 進化的アーキテクチャ探して読むんだと思った