@hihihiroroのLog

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

「プロダクションレディマイクロサービス」を読んだ

プロダクションレディマイクロサービス ―運用に強い本番対応システムの実装と標準化

プロダクションレディマイクロサービス ―運用に強い本番対応システムの実装と標準化

マイクロサービスを標準化するためにガイドにする本だと思う。この本の中では、プロダクションレディには以下の項目を備えている必要があると書かれている。付録に各項目についてのチェックリストと評価基準が纏まっているので使えそうだった。

安定性
信頼性
スケーラビリティ
耐障害性
パフォーマンス
監視
ドキュメント
大惨事(カタストロフィ)対応

第1章でマイクロサービス入門がまとめられている。アーキテクチャの基礎、モノリス→マイクロサービス二分割する際の問題について、マイクロサービスエコシステム、マイクロサービスアーキテクチャを導入する際の組織として課題などがまとまっている。

その後の章ではマイクロサービスを作る際の原則をそれぞれの目的毎にまとめられている。

  • 安定性と信頼性を備えたマイクロサービスを作るための原則(3章)
  • スケーラブルでパフォーマンスの高いマイクロサービスを作るための原則(4章)
  • 大惨事に対する備えができたタイ障害性のあるマイクロサービスを構築するための原則(5章)
  • マイクロサービスの監視についての原則(6章)
  • マイクロサービスの適切なドキュメント、アーキテクチャと組織運営の原則(7章)

この中だととても気になって関心を持って読んだのは、監視とドキュメント。

監視

監視すべきものが何かが決まってないと見れているかどうかもわからない。本書ではマイクロサービスが健全性か見分けれる監視項目と主要メトリックとしてまとめている。主要メトリックにはアプリケーションだけではなくホストレベルのメトリックも含まれている。
また、ロギングについてロギングするべきもののガイド、ロギングしてはならないもののまとめがされている。
主要メトリックをダッシュボードにまとめて表示することを必須としている。ダッシュボードを見ただけでマイクロサービスが正しく動作していることがわかることが大事だ。
すべての主要メトリックニは、正常、警告、危険の3種類のしきい値を決め有効なシグナルが送れなければいけない。また、危険のシグナルが送られてきた場合、すぐにアクションができることが必須とされていた。アクションするためには次のドキュメントにも続いていた。

ドキュメント

途中のコラムで「READMEとコードのコメントはドキュメントではない」と書かれている。マイクロサービスのドキュメントは一元管理、共有、かんたんにアクセスできるが必須とのこと。アプリケーションが回収された際にドキュメントが更新漏れがないように開発サイクルに更新することも含めるのが大事だ。まったくもってその通りだと思った。後で直そうと思っても、忘れたり面倒くさくなったりで、結局更新しないことを何度も経験しているのでルールとして置くことが大事だと思った。

ドキュメントに書かれるべき項目は以下。

  • 説明
  • アーキテクチャ
  • 連絡先とオンコール情報
  • リンク
  • オンボーディング/開発ガイド
  • リクエストフロー/エンドポイント/依存関係
  • オンコールランブック
  • FAQ

連絡先、オンコールランブック(トラブル時の対応方法、デバッグ方法)、FAQ(サービスについて聞かれることは何でも)はあると便利だなと思った。特にランブックの「午前2時の眠い開発者でも理解できるように書く」はそりゃそうだと思った。夜中でアラート対応などの際にいちいちドキュメントやコードをしっかり読んで対応方針考えてとか辛い。

まとめ

  • マイクロサービスだけではなくモノリスでも、サービスを運用するときに必要なポイントが原則としてまとまっていた
  • 最低限本書に書かれている原則は守って信頼性向上をするためにみんなで頑張ろうと思った
  • 各章終わりや付録にチェック項目がついているので自分のサービスに対してできてる、できてないを洗い出して良くしていきたい
  • Mesos がよくでてきたな

マイクロサービスアーキテクチャ

マイクロサービスアーキテクチャ

マイクロサービス入門 アーキテクチャと実装

マイクロサービス入門 アーキテクチャと実装

「業務システム クラウド移行の定石」を読んだ

毎年通りお盆で実家に引きこもっているので本を読んでいる。

業務システム クラウド移行の定石

業務システム クラウド移行の定石

転職したのでクラウド移行しなくても、触っているのだが積ん読になっていたので読んだ。
架空の中小商社が初めてクラウドを導入するという話仕立てで書かれている。170ページくらいの薄い本なので一気読みができた。

本の大項目は、

  1. 企画
  2. 戦略・分析
  3. PoC(実証実験)
  4. 設計・移行
  5. 運用と改善

それぞれのフェーズでも何回も言われているが、この本では本当にクラウドの移行するのが良いか考えることをすすめられる。クラウドがどこでも使われれるようになっているからうちでも使おうとかんたんに考えるだけで導入すると後々辛いことがある。
クラウドに限った話でなく、新しくシステムを作るときにもシステムを移行するときにもクラウドを使う場合でも、オンプレミスの場合でもそれは変わらない。

本書ではクラウドの特性、現状把握の仕方、目的の立て方、実験する理由、移行するための設計、すすめる順番などがわかりやすく書いてある。最後の章の運用と改善についてはとても大事だとクラウドを触っていると思う。クラウドではすぐに新しいサービスがリリースされるし、機能が追加される。その動きに合わせて、システムの改修をしたりアーキテクチャの変更をしたりと止める事ができない。
その為に、定期的に監視しなくてはいけないものがあり、取得したデータをどう使った方が良いかが書かれている。移行が終わりではなく、その後もシステムは使われ続けるのだからここまで書いてあるのはとても助かった。

まとめ

  • クラウド導入に限らずシステム移行時に考えなければいけないことがまとまっていた。
  • プロジェクトをすすめる際に、早く出すことの重要性やPDCAを回すことが説明されていてわかりやすかった
  • PoC で困らないようにいろいろなクラウドサービスを触っていこうと思った。

GCPの教科書

GCPの教科書

201907 振り返り

暑くてやる気が出ない。
どうやら左鼻にポリープができてしまったらしく息ができてない。
常に鼻が詰まったような話し方になってしまう。
口呼吸が多いので喉がずっと痛い。と良くないことになっている。
ちゃんと病院に行かねば。

それ以外は夜まで仕事してお酒飲んでをしているので比較的健康です。

べんきょうかい

半分キャンセルしてしまった。
なんか最近は残るようになってしまって良くない。

Google Cloud Nextは自分でGCPを触るようになって初めて行った。やっぱり色々便利。

ほん

漫画いっぱい読んだけど家の本が減ってない。。。
電車の中で本を読むのは慣れたから2、3冊は消費できるようになるんじゃなかろうか。
しかし技術書は読まなくなってしまったなー。

えいが

いっぱい行った。
藤原竜也が求めていたのと違くて少しガッカリ。
それ以外は想定どおりで面白かった。天気の子を小説を読む前に見れば良かったなと少し後悔。

ぶろぐ

読んだものをつらつらと。
イベント参加とかみんなすぐ書いててすごいなとおもうので、本の感想以外も書いていきたい。

medium.com

hihihiroro.hatenablog.com

hihihiroro.hatenablog.com

「オープンソースがよ〜くわかる本」を読んだ

図解入門ビジネス 最新オープンソースがよ~くわかる本

図解入門ビジネス 最新オープンソースがよ~くわかる本

最近隣の人たちが開発しているものをオープンソース化しようかという話を聞いた。
自分でもオープンソースを使ってプロダクトを開発しているし、できれば自分が関わっているオープンソースには何かできるだけの恩返しをしたいなと思った。そう考えたところで普段使っているけどライセンスとか詳しくは知らないなと思ったので調べるために読んでみた。

本書の内容は以下。

1章 人工知能もFinTechもビッグデータも、みんなオープンソースでできている!
2章 オープンソースを理解する
3章 オープンソース普及の歴史
4章 IT業界の動向とオープンソース
5章 SIビジネスは崩壊する?
6章 オープンソースビジネスとは
7章 オープンソースの問題点
8章 オープンソースビジネス、成功へのポイント
9章 今おすすめのオープンソース
オープンソースの説明から、オープンソースを使った商売の話も書いてあって面白かった。

その中でも特にライセンスについて今回は書いておく。

コピーレフト

コピーレフトを採用しているオープンソースと組み合わせて使う場合、オリジナルのソースコードオープンソースにする必要がある。
つまり、コピーレフトを採用しているオープンソースを改変した際には、修正または付加したコードに対しても元のオープンソースのライセンスを適用する必要がある。また、独自のソフトウェアに対して、部分的にオープンソースを組み込む場合でも、独自のソフトウェア全体に対して、元のオープンソースのライセンスを適用する必要がある。

  • GPL(GNU General Public License)
    ソースコードの公開を原則とし、誰でも自由に入手、使用、改変、再配布できる。
    また、GPLのプログラムを改変し、独自に開発したプログラムの一部として組み込んだ場合などには、これらのプログラムにもGPLを適用してソースコードを公開しなければならない。(コピーレフト)

  • LGPL(Lesser General Public License)
    GPLをベースとしているが、コピーレフトの特性を緩和している。
    例えば、独自に作成したプログラムからLGPLで公開されているオープンソースのライブラリを動的リンクで呼び出した場合、呼び出し元のプログラムにはLGPLを適用する必要がないとされている。
    同様にコピーレフトが緩和されているライセンスとして、MPL(Mozilla Public License)、CDDL(Common Development and Distribution License)などがある。

  • Apache License
    コピーレフトの特性が無く、Apache Licenseのオープンソースを改変したり、派生したりしたソフトウェアに対しても、独自のライセンスを適用することができる。
    同様にコピーレフトの特性が無いライセンスとして、BSD License(Berkeley Software Distribution License)、 MIT Licenseなどがある。

まとめ

ライセンスについてはなんとなくだけど分かった。
貢献するために次は行動してみようと思う。OSS Gate という取り組みがあるらしいのでまずは参加してみようかなと思っている。

OSSライセンスの教科書

OSSライセンスの教科書

oss-gate.github.io

「正しいものを正しくつくる」を読んだ

読んでみた。
本の下1/3は解説用に空いているため、思っていたよりは早く読み終えることができた。(分厚かったため読み終えるのに時間がかかると思っていた。

本書はプロダクト開発がなぜうまくいかないのかから出発して、筆者なりのうまく進めるためのプロダクト開発のやり方を紹介している。
本書の中では、プロダクト作りがうまくいかない理由として多様性の問題を挙げている。

  • プロダクト自体の多様性
    • SoR, SoEなど、開発するプロダクトに求められる多様性
    • プロダクトを作る技術の多様化
  • 作り手側の多様性
    • 開発チーム内の役割
    • 経験による多様性
    • 働き方による多様性

多様性によって不確実性が高まっているためプロダクト作りが難しいと説明がある。

その後、不確実性をなくすための手法やチームのあり方について説明をしてある。この本に限らず、最近は不確実性って単語をよく見るような気がする。

少しでも開発をしていて大変だと思ったり、困ったなと思っている人は気になった箇所だけでも良いから読むと良いのかな。

カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで

カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで

201906 振り返り

咳は出なくなったが、ずっと鼻がつまっている。最近話をしている人たちは聞き取りづらいだろうなと思い申し訳ないと思っている。
そろそろ耳鼻科に行ってみることなのかな。
職場でテストをやる機会があったのだが、自分のできなさ加減が悲しい。新しいことが身についているかと言われるとそうでも無いし、古いのは忘れていくし退化しまくっている気がする。
クビになってしまう前に、基本の勉強をして基礎の勉強もしていきたいなと思う。

べんきょうかい

1万円払って休日に参加してきた。
何個かの時間はセッションを聞かずにエレベータホールで本を読んでいたのだが、その時に色々な人に話しかけられ、そこで話をしたのが一番参加意義があったのではないかと思っている。
何か僕も発表できるようなことをしていかないとな。
今回は色々な人が発表していて参加してみて思ったが普段話す人はご飯だったり呑みだったりで話をするので、今後はあまり関わりの無い人の話を聞きに行くようにしようと思った。

ほん

カードの使い道見てて流石に本に使いすぎだなと思った。
家にいっぱい積んであるのに(文字通り縦に積んでいる)買った本を読んでいるだけである。
引っ越しを考えてもいるので、部屋の荷物を減らす意味でも知識を増やす意味でも読んでいかないといけないな。

えいが

半年で30本観ることができた。
ピカチュウが思ったよりも面白かった。映画館近くにあるのに、最近は仕事帰りに行けなくて悲しい。
さよならくちびるはSpotifyで家でよくアルバムを聴いている。

201905 振り返り

咳が止まらない。病気になった後の回復がものすごく遅くなってしまった。
仕事内容は変わってないのに、帰る時間がだいぶ遅くなってきている。
仕事している=長時間会社にいるみたいになってきてるから良くない。

とりあえず体調を良くしたい。

べんきょうかい

今まで自分がやってない内容の話を聞きに行ったのでたのしかった。
セキュリティとかテストとかの話をもっと聞きに行きたいと思うけど、そもそも使う技術について勉強しないと。

ほん

休日は寝ている時間が長くなってしまったので、消費する速度が遅くなった。
ほぼほぼ今月買った本を読んだけど、積ん読が増えなかったので一安心。

えいが

休日は寝ている時間が長くなってしまったので、消費する速度が遅くなった。
続きも是非やって欲しいところで終わった。

  • KINGDOM