@hihihiroroのLog

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

「[実践]データ活用システム開発ガイド」を読んだ

同僚の方々が書いているとのことで気になったので読んでみた。

目次は以下。

  1. コンセプトサマリー
  2. データの収集と蓄積
  3. Web API 基盤
  4. 施策の実施と効果検証
  5. データパイプライン・ワークフローエンジン
  6. データレイクとデータウェアハウス
  7. API 基盤の発展

データの連携に関しては仕事として行っているので知っていることが多かった。
構造化データや非構造化データ、トランザクションデータやマスタデータなどのデータの種類によってのデータ収集の説明などがあってわかりやすかったが実際にやってみるとそのまま上手くできることって少ないんだよなというのが自分の印象。
ただハンズオンがついているので実際にデータを取って入れてを体験できるのは面白かった。

データを使って施策を行う活用例としてAPI の作成を行い提供を行うことが紹介されている。データを貯めることは行っているが実際に役立てるところはあまり関わっていないのでAPI として上手くデータを使っている例が読めて面白かった。
また、施策を行うための計画から効果検証までについて詳しく説明されていて勉強になった。施策を行うのは簡単なのかもしれないが、それが上手くいったのかの確認や止めるタイミングを先に考えておくのは大事だなと思った。事業について考えるのと一緒なんだろうな。

データレイクやデータウェアハウスは規模やタイミングによって色々あると思うのでこれは一例だと思って読むのが良いのかなと思った。データを一箇所に集めることなく散らばっているまま上手く使えることが求められていると最近は思うことが多い。次回作ではぜひとも散らばっているデータでも上手く活用できるようにデータの見つけ方や、メタデータなどについても詳しく書かれていると嬉しいなと思った。

まとめ

  • データを取得、施策利用までの流れがまとまっていて読みやすかった
  • 色々詰め込むために薄くなっているところもあると思うのでそれは他の本で補いたい
  • 仕事も忙しい中角の大変だったろうな。おつかれさまでした

「現場で使えるkubernetes」を読んだ

現場で使っているので読んでみた。

現場で使えるkubernetes

現場で使えるkubernetes

Amazon

目次は以下。

CHAPTER 1 速習Docker/Kubernetes
CHAPTER 2 KubernetesのエコシステムとCustom Resources
CHAPTER 3 Kubernetesアプリケーション開発の実践
CHAPTER 4 Kubernetesのセキュリティ
CHAPTER 5 Kubernetesの運用

5章立てだが、そのうち4章のセキュリティが半分くらいのページを占めている。
そこからもタイトル通り現場で使うことを目的に書かれているのだろうなということが分かる。
1〜3章では、Kubernetesアーキテクチャからマニフェストや設定を管理するためのKustomize、Helm などのツールの説明やKubernetes Cluster 構築からサンプルアプリケーションのデプロイまでがサクッと試せるようになっている。

セキュリティについて書かれているのは以下の内容。

  • ホストOSのセキュリティリスクと対策
  • コンテナのセキュリティリスクと対策
  • コンテナO家ストレータのセキュリティリスクと対策
  • コンテナイメージのセキュリティリスクと対策
  • コンテナレジストリのセキュリティリスクと対策
  • ハードウェアのセキュリティリスクと対策
  • コンテナネイティブなセキュリティ製品

コンテナ環境で攻撃対象として想定されるものに対して、起きやすいセキュリティリスクと、それらに対する対策について解説されている。セキュリティの考え方としても自分でやるべきところ、クラウドベンダに任せるところが紹介されておりわかりやすかった。
ユーザをroot で動かさないや、RBAC で最小の権限を付与することを徹底するなど知っていることも紹介されていた。それ以外にもエンドツーエンド通信の暗号化やNode へのPod スケジュール制御としてNodeSelector、Affinity/Anti-Affinity、Taint/Toleration などが紹介されている。用語としては知っているが使っていないものも多かったので勉強になった。
また、実行環境だけではなくそもそものコンテナイメージに対するセキュリティ対策も説明がある。最小限のパッケージだけをいれる、脆弱性調査を行うなど。レジストリに対しても通信を暗号化するやイメージのライフサイクル管理、タグの命名規則など起こしやすいトラブルについての対応も書かれていた。
基本的なログを出力するや検知についても説明されており、Kubernetes に限らない話だなと思った。当たり前のことをまずはしっかりと設定していることを確認するところからだなと。

最終章では運用について書かれていた。
レジリエンスを最大限に活かすための設定についてかかれている。Kubernetes を使うならばレジリエンスを最大限に高めようという考え方は同意ができる。 具体的にはノードのスケーリング、Pod へのPriority 設定やAnti-Affinity 設定を行うことで重要度の高いPod を優先的、きれいな分散を行うようにできることが分かる。またProbe を正しく使うことでコンテナの正常性確認を行ってから使えるようにすることが紹介されている。
メトリクスの収集を行うことでのモニタリング、アラート通知の仕方やログの種類と収集方法が紹介されている。このあたりはアプリケーションでも行うべきことなのでわかりやすい。ただこのあたりはトラブルが起きた際にはとても必要になるのでしっかりと設定しておきたいなと思った。

また、サービスメッシュについても説明されている。Kubernetes を使ってマイクロサービスを運用する上では必要になってくるものである。そこまでのアプリケーションをまだ作ったことがないのでまだまだこれから勉強する内容だなと思っている。それ以外にもトラブルシューティング時の見方や使えるツールの紹介、Cluster のアップグレード時期についても説明がされている。このあたりは運用していると地味に考えたり実施することが多い内容だなと思いながら読んでいた。

まとめ

  • 運用目線での話が多く載っているので面白い
  • セキュリティや運用について考えてみることは大事
  • せっかくKubernetes を使うんだからレジリエンスを最大限にできるように考えれるようにしたい

「エンジニアリングマネージャーのしごと」を読んだ

現在はチームリーダーとして働いている。
ただし、メンバーに対してのマネジメントなどはちゃんとできていないと思っている。そのあたりをどうしていくのが良いのかと思っていたので、研修を受けたり本を読んだりしている。
エンジニアとしてやっていくための技術的な勉強はこれまで積極的にやってきたが、人のマネジメントやタスクの管理などについては知識としては知っていることがいくつがあるか勉強をちゃんとしてきたわけではない。エンジニアとしては別のスキルが必要になると常々思っていたので読んでみた。

本書の内容は訳者の一人であるryuzee さんがまとめているスライドがわかりやすい。

www.ryuzee.com

人やタスクを管理する前にまずは自分を管理することが紹介されているのが面白い。
ツールやルールによる管理で自分のやるべきことに迷って時間をかけないことは大事だなと思った。他の人にやってもらうためには自分でまずは実践していることが大事ということはわかる。まずは自分の管理ができるようになるため時間をかけてみようと思う。

そして、マネジメントの仕事としては4分類が紹介されていた。
これらの4種類に自分の仕事を当てはめて考えることで、自分がこれをやったと言えるようにして満足感を得ることが紹介されている。

  1. 情報収集(1on1、雑談、Slack など)
  2. 意思決定(採用、チーム構成、作業見積もり など)
  3. ナッジング(決定への影響、意見の主張 など)
  4. ロールモデル(積極的に議論をする、技術面貢献 など)

また、マネージャーは自分で手を動かすのではなく、人に仕事をやってもらうことが必要だと紹介されていた。ただし、委譲する際にはどこまでと何を委譲するかは気をつけなければいけないことが説明されている。適切に委譲が行えていない例として2つ紹介がされていた。
1つ目はマネージャーが細かいことまで関わってしまい委譲ができてない状況。
2つ目はメンバーにすべてお願いしてタスクを忘れてしまう丸投げが説明されていた。
これら2つは委譲のアンチパターンとして紹介されていた。

自分は委譲ができていないことが多い気がする。気になってしまいタスクによく口を出してしまうなと思った。
そして委譲には実行責任と説明責任の差を理解するのが大事という話が書かれていた。
タスクを求められる品質で完了させる責任を持つ説明責任とタスクを実際に行う実行責任。これらをメンバーによってどこまでの塩梅で委譲するかを考えていこうと思った。

それ以外にもマネージャーの仕事として以下のようなことも紹介されていた。

  • 日常を通しての部下や周囲、自分の上司との接し方
  • 1on1
  • 評価やフィードバック
  • 採用や退職
  • 社内ネットワーク
  • キャリアアップ
  • 職場環境整備

やることはたくさんあるらしい。上記で気になったことから順番にやれるようになっていこうと試していこうと思う。

まとめ

  • マネージャーがやるべきことは多岐にわたっているので身につけていくのは大変そう
  • 細かい方法論についても説明がされているので順番に見に付けていきたい
  • マネジメントの仕事として紹介されている4種類を満遍なく手を出していく

202211 振り返り

なんかわからないけど最近忙しいなと感じることがある。
12月も近いからなのだろうか。今月は飲み会がいっぱいあったのでそのせいなのかもしれない。
コロナで人と会わない生活が長いのに急に連続で人に会うことが増えるとたしかに疲れる。
12月は少しゆっくり仕事しよ。

べんきょうかい

久しぶりに最初から最後まで勉強会を見ることができた。
お仕事で関わっているので気になっているところを見れたり考えることができたので面白かった。

ほん

おすすめされていた本をいくつか読むことができた。
どれも面白かったし、買った小説も面白かったので今月の読書活動は満足。

えいが

今月は色々見に行くことができた。
アニメが多かったけどどれも面白かったな。大きい画面で見るのはやっぱり良いな。

ぶろぐ

やってる仕事に近いんだろうなと思ったので読むことにした。

hihihiroro.hatenablog.com

「クラウドエンジニアの教科書」を読んだ

クラウドを触っているエンジニアなので読んでみることにした。

目次は以下。

CHAPTER-1 クラウドの概要
CHAPTER-2 クラウドエンジニアの定義
CHAPTER-3 クラウドの世界観
CHAPTER-4 クラウドのユーザ管理と権限設定
CHAPTER-5 クラウドの認定資格
CHAPTER-6 クラウドを試してみる
CHAPTER-7 クラウドを使ったシステムの費用
CHAPTER-8 クラウド上でWindwosを扱う
CHAPTER-9 Infrastructure as Code
CHAPTER-10 クラウド上でコンテナを扱う
CHAPTER-11 マルチクラウド構成
CHAPTER-12 IaaSやPaaSの監視

本書ではクラウドエンジニアをクラウドサービスにおけるシステム設計、構築、運用などを担当するエンジニアをさしている。クラウドエンジニアに求められる技術としては次のようにたくさんのものが紹介されている。サーバー・OS、ミドルウェア、ネットワーク、セキュリティ、プログラミング、監視・運用、障害対応、各社クラウドサービスの知識と経験など。部署に分かれて作業を行っていたことがクラウドになるとできる作業が増えるからか、それに伴い面倒をみないといけないものが増えるように思える。ただ、本書の中にも出てくるがオンプレを使っている経験があればクラウドが分かっていなくても想像がつくことはある。
オンプレの経験が無駄になることはまったくない。

使ってみて思うのは、簡単に変えられるからと言っても最初の設計がやはり大事だと思う。その中でも大事なのはユーザ権限設計とネットワークかなと思っている。そのうちの一つであるユーザ管理と権限についてはCHAPTER-4 で紹介されている。AWS、Azure、GCP のそれぞれでの説明がされている。ここで基本的な考え方を読んでおき、実際にそれぞれのクラウドを使う時に詳しく調べるのが良いと思っている。

いくつかのCHAPTER では実際に試してみることができる箇所がある。無料枠の中で試せる内容ばっかりなので、触ったことない場合はぜひとも試してみるのが良いと思った。結局ハマりどころなどは実際に使ってみないとわからないことが多いので。

監視が大事なのはクラウドだけではないが、クラウドでは特にオンプレでは見なくても良いところも見る必要があったり、見といた方が良いと思うことが多い。利用料もそのうちの1つだと思う。ただ監視項目はいくらでも増やせることができてしまうので、見なければいけないものをまずは定義することが大事なのかなと思っている。それさえ決まってしまえば実装するだけになるので、まずは見るべきものをちゃんと決めることから。

クラウドエンジニアの方向性についてもまとまっていたのでそちらを最後に記載する。

  1. 基本サービスの利用に長けたクラウドエンジニア
  2. 応用サービスをよく知っているクラウドエンジニア
  3. 特定分野に特に長けたクラウドエンジニア
  4. クラウドインフラからアプリ開発までカバーするフルスタックエンジニア
  5. 組織の管理者
    クラウドエンジニアの教科書 P.45

まとめ

  • これからクラウドエンジニアになるぞと思う人が読むと楽しそう
  • クラウドエンジニアの方向性がまとまっていて目指す方向性を考えようと思った
  • クラウドだろうとオンプレだろうと基本は一緒だな

インフラエンジニアの教科書

インフラエンジニアの教科書

  • 作者:佐野裕
  • シーアンドアール研究所
Amazon

202210 振り返り

急に寒くなったなと思う日が増えたので気をつけないといけない。
もともと病気になりやすい方なのだが、社会人になってからは気をつけているからか身についた肉のおかげかあまり病気になっていない。
ただ、潜在的にあぶなそうなので最近は真面目にあすけんをつけてみている。
運動を全然していないこともそうだが単純に食べすぎているので気をつけてみよう。

べんきょうかい

イベントに久しぶりに参加した。 しかしどちらも途中までしか見ていないので全部出ることができなくなってしまったなー。

ほん

ここ最近の中ではいちばん小説を買って読めた気がする。
他にもコミック以外も読んでブログにまとめてみたりできたので、来月以降もペースを守れるようにしたい。

えいが

あまり観に行くことができなかった。
いくつか今やっている映画で観たいものはあるので来月はもう少し観に行きたいな。

ぶろぐ

時間があったのか読み終わった本の感想を書ける事が多い月だった。
Docker 周りの本は未だに読めるので知識としては身についているのかなーと思った。

hihihiroro.hatenablog.com

hihihiroro.hatenablog.com

link.medium.com

hihihiroro.hatenablog.com

「アジャイルプラクティス」を読んだ

今年の誕生日に自分で買っていたのを発見したので読むことにした。

内容としてはアジャイルとは、などの話ではなく現場でアジャイル開発を行うためのプロくティスが45個紹介されている。それぞれが関係があるものだったり、それ単体でやるべきことなどが紹介されている。その中でも気になったものをいくつか書き出してみる。

人ではなくアイデアを批判する

これはちょっと前に読んだ本でもあって誰が出したかではなくそのアイデアで問題が解決できるのかに注目することが大事。ベストなアイデアを出す前にメンバで何を持ってベストとするか認識合わせしておくのが良いというのはそうかもと思った。

時が来たら習慣を捨てる

今までができていたからと言ってそれが本当に良いことなのか、他に楽になることがないのかを探さないことがままある。現状のやり方を踏襲するのが楽なことは多いけど、現状に合わせて考え直すことも大事だなと思う。

技術の採用根拠を明確にする

今動いているシステムがなぜこのアーキテクチャで組まれているのかがわからないことが多い。他にも同じことができるもので簡単にできそうなものがあった時に変更してよいのかどうかの判定が難しくなってしまう。そういうことがないように何故選んだのか、何を大事だと判断したのか、何を選ばなかったのかなどが分かる資料があると良さそう。
Architectural Decision Records (ADRs) などを見かけることも増えてきたので書いてみたい。

役に立つエラーメッセージを提供する

エラーがログに出ていることはだいたいだが、役に立つかどうかというとまた別の話となる。エラーが起きただけではなく、どこでどんなエラーが起きているかなど必要と思えることは分かっているのにそれをログにだせてないことがたまにある。開発をする際にはエラーが起きた時のことも大事だなと思った。

まとめ

  • 悪魔のささやきに耳をかさないようにしよう
  • 他のメンバーに迷惑がかからないように下準備などはしっかりしよう
  • 当たり前のことをサボることなくやるべきことをやろう