Software Design 2020年1月号より「マイクロサービスアーキテクチャ」

表題の特集を読みました。ページ数は少ないので、さっくりまとめられていいですね。自分はマイクロサービスについては初心者です。

全体として

マイクロサービスはどれくらいの大きさになるのかというのは、初心者の自分が最初に思い付いた疑問です。

特集を通読すると、若干の幅があるように感じます。一番細かく刻んでいるのは、第1章の増田さんだと思います。例えば、「顧客管理」では大きすぎであり、「顧客識別情報」「取引履歴」「連絡先」等々への分割を試みるべきとしています。

この段階で、新たに二つの疑問が生じました。一つは、「マイクロサービスに階層はあるのか?」というものです。説明を読んでいると、なんとなく階層はないようなイメージがあります。まぁ、階層化できるくらい強い依存があるのなら、最初から一つでいいような気もする・・・のでしょうか?

もう一つの疑問は、「マイクロサービスはいくつまでならバラして大丈夫なのか?」というものです。大丈夫というのは、メリットがデメリットを上回っているのか、に置き換えていいです。

メリットは以下が挙げられていました。

  • 変更にかかる時間が短くなること、コストが下がること

デメリットには以下が挙げられていました。

  • 通信のオーバーヘッドが発生すること
  • 障害発生時の原因追跡や復旧が難しくなること
  • 全体像を理解するのが難しくなること

なんとなくですが、二桁後半あたりから、人間の頭では全体像を理解できなくなってきそうな気がしますね。

以下、各章を見ていきます。

第1章 マイクロサービスって何? アプリケーションを「ばらばら」にする理由

アプリケーションをいくつかのサービスに分割します。分割というのは、実行環境を分けることです。そうして分割されたサービスをマイクロサービス(複数形でマイクロサービシズ)としています。

マイクロサービスが低コストになった理由に、実行環境の仮想化や、クラウド上で実行できるサービスの拡充が挙げられていました。これについては、自分の理解が不十分な気がしています。テスト*1・デプロイが簡単・自動になったからコストが下がったという理解であっているのでしょうか?

マイクロサービスのサービスの結びつきとして、「同期・非同期」および「直列・並列」の2軸で説明されていたのは、非常にわかりやすいと感じました。

第2章 ひとつひとつのサービスはどのように作れば良い? モノリシックなサービスを上手に切り分けるコツとは

まず、どう分けるか?どれくらいの大きさで分けるか?という話がありました。ここについては分かりやすく、特に変だなというところはありませんでした。

非同期的なサービスでも、アクターモデルとイベントモデルの2つがあると述べられています。個人的には、イベントモデルに若干かすったことがある程度で全然わからんのですが、とにかくパフォーマンスを上げる、もしくはスケールさせるために同期を捨てている、という感覚は持っておきたいと思いました。

面白かったのは、サービス間の(通信)プロトコルが何が適しているかというトピックで、HTTP(REST)がトップだったことです。すごいぞHTTP。ちなみに次におすすめされていたのは「クラウドサービスの独自プロトコル」でした。マネージドサービスで、非同期的なイベントモデルを扱うのに適しています。逆に言うと、シンプルな同期的な結合であった場合は、慣れ親しんだHTTPで問題ないということですね。

一つ気になったのは、購入キャンセルの例で

購入キャンセルのイベントに対して各サービスの動作がきちんと整合していなければなりません。システムとして全体の状態を管理してトランザクションするしくみになっている必要があるでしょう。

とあるのですが、そのトランザクションの仕組みをどう確保するかは相当大事なのでは・・・と思いました。直後に書いているRedisのPub/Sub機能とかはイベントモデルを実現する手段に過ぎないようですし。

第3章 サービス同士はどのようにつなげればいい? 作って学ぶBackends For Frontends

いくつかのマイクロサービスから返ってきた結果をまとめ、クライアントに返すBFF(Backends For Frontends )が紹介されています。ここらへんからマニアックになっていきます。

Server Side Rendering は名前くらいは聞いたことありますが、マイクロサービスの文脈で語られるのだなと思いました。多分他の背景もあるような気がします。しかし、Next.jsをVueのライブラリだと思っていた自分には全然わからない。

第4章 複雑なマイクロサービスをどのように管理すればよい? サービスメッシュを実現するIstioとOpenShift Service Mesh

サービス個別に監視ツールを導入したとき、システム全体の監視はどうするのかという問題があります。サービスメッシュとは、新設したサービスメッシュ層で監視に必要な情報(ログ)を収集する仕組みになります。

正直難しすぎてよく分かりませんでした。ただ、数が増えて全体的な監視が難しくなった時の解決策として、最近注目されているようです。

おわりに

自分みたいな何もわからない人から、ガチ勢まで読ませる内容だと思います。

一点気になったのは、字数を収めるために、日本語が若干おかしいような印象を受ける文がいくつかあったかなということです。削りに削って、いま自分が読んでいる文章があるのだなと察せられます。

*1:特にエンドツーエンド

JJUG CCC 2019 Fall参加記

JJUG CCC 2019 fall に参加しました。

こんな感じのタイムテーブルで行われた、大規模なJavaカンファレンスです。

https://ccc2019fall.java-users.jp/timetable.html

今回から、講演の一部が「ステップアップセッション」という初心者向けとしてラベル付けされていました。

参加したセッションの多くがこのステップアップセッションになりました。

Gradle を完全に理解した人が、何も分からなくなるための第一歩

資料は以下です。

qiita.com

QiitaでJavaといえばこの人です。

「今年はGradle結構やったのでアウトプットしてみました」ということを話していて、今までたくさんアウトプットしている人も新たにチャレンジしていてすごいなと思いました。

スライドの具体例がとても丁寧で分かりやすいです。

自分はGradleは初心者未満でした。たまに、ちょろっとライブラリを増やすとかくらい。

とはいえ今回のセッションで、「じゃあ明日からbuild.gradleのメンテよろしく!」って言われても泣きながらOKできるレベルにはなりそうな気がします。

入門 例外

資料は以下です。

github.com

独自例外クラスの中に、finalのプロパティを持たせて、受け手に情報を渡せるようになります。

例外を「投げる」ときはその名の通りthrowを書くのですが、その理由が説明されていたのが良かったです。ちなみに、 メソッドの実行を終了し、失敗したと呼び出し元に通知できる からです。

資料のよくわからないところを聞いてしまったが、資料のアラを突っ込んだ野暮なものでした。とりあえず雰囲気をつかむところが大事なのかなと。

入門ということで詳しく説明されませんでしたが、実際try-with-resourceで書くときのリソースって何なんでしょうね?ファイルとか?

DBアクセスとかはもう少し汎用的なところで書くような気がする。

これはステップアップセッションになっていませんでしたが、それに入れても良いかなと思いました。

まだまだ間に合うJUnit(再)入門

資料は以下です。

自分がJUnitに関して初心者であること、JUnit4から5に移行したいと考えている身であることから、お役立ちのセッションになりました。

アノテーションが導入されていたのがJunit4からだというのは初めて知りました。3以前は使ったことがないので。

Junit5だと、クラスやメソッドがpublicじゃなくてもいいのかというのはあまり意識していませんでした。まああんまり関係ないような…?

Junit5への移行のメリットとして、assertAllで全部のテストを実行してくれることがありそうです。

Junit4だと一か所でも落ちると、以降を実施してくれないので、Assertionを複数おいている場合はフラストレイティングな気がする。

JVM入門 -Javaプログラムが動く仕組み-

資料は以下です。

講演者がめちゃくちゃ緊張していた気がします。

JVMについて全く中身を勉強したことがないので、「こんな用語があるのか~」くらいの感想でした。

GCについては時間を割いて説明されていました。いくつか種類があるのを初めて知りました。以下の記事などを見て勉強したいと思います。

gihyo.jp

絵で説明しているのでふわ~とイメージが頭の中に入っていく感じでした。

今回出てきた用語を追うことでさらに理解が深められると思いました。後ろに参考資料もついています。

DIコンテナ入門

資料は以下です。

backpaper0.github.io

このころには大体燃え尽きているのでいいセッションがなかったら帰っているのですが、今回はスピーカー・内容ともに楽しみだったので参加しました。

まず、DIの仕組み、および内部生成ではなくインジェクションを使うメリットが説明されています。今までなんとなく把握しているものの、うまく説明できないレベルでしたが、今回はっきりしました。

Beanとコンポーネントは大体一緒というのは「そうなんだ、よくわからなかったけどそりゃ分からんわけだ」という感じでした。

講演者は、主観だとしたうえで、フィールドインジェクションよりコンストラクタインジェクションを使うべきだとしました。

ただ、自分のIntelliJ IDEAだと、フィールドインジェクションはコンストラクタインジェクションにするように警告されます。かなりはっきりとコンストラクタインジェクションを使うべきと言っていいと思います。とはいえ、その理由がよくわかっていなかったので明快になってよかったです。

まとめ

今回のセッションは、自分の興味を惹かれるものがたくさんあってよかったです。

ステップアップセッションのレベル感は自分の予想した通りで、それも良かったかなと。ほぼ全く触ってない分野はちょっと難しいなと感じますし、少しやっている分野については有意義という感触でした。

来期もこの枠組は設けて欲しいなと思いました。

おまけ

初心者向けは埋まるのが早いのでキャパをチェックすべきでしょう。私は一つのセッションが満員で入れませんでした。

紙でもらったタイムテーブルにはキャパが記載されていますが、HPだとないですね。

嫉妬と向き合う

最近「嫉妬なんかダサい、自分を高める努力をしろ」的な言説をよく見ます。個人的には大筋賛成なのですが、モヤっとすることもあるのでもう少し細かく言語化しようと思いました。

まず、先ほどの主張はざっくりすぎるので、以下の3つに分解しました。

  1. 嫉妬感情は醜い

  2. 嫉妬で他人の足を引っ張ってもお前の人生は豊かにならない

  3. そういうのを止めて自分を高める努力をすべき

嫉妬感情は醜い

自分の考え:そうでもない。

感情そのものを否定する考えは自分にはないです。なくすことも難しいんじゃないかなとも。感情が出てくるのはしょうがないですが、その後の行動をどうするかの方が大事だと思います。

嫉妬で他人の足を引っ張ってもお前の人生は豊かにならない

自分の考え:決めつけはよくないと思います。

相対評価を気にする人の場合、自分より上にいる人を叩き落せば、幸せになると思います。他のパターンでいうと、正義感を持って見知らぬ人をぶっ叩くと幸せになると聞いたことがあります。

あまり表に出しませんが、僕も他人の不幸話は嫌いではありません。とはいえ、周りにそこまでしたい人もいないし、よく知らない人を叩くのは悪いことだと思っているので上記のような行動を起こしていません。

そういうのを止めて自分を高める努力をすべき

自分の考え:上から目線が気に食わないが、内容は同意

自分もそう思う主張なので特に追加したいコメントはありません。

まとめ

そういうわけで、冒頭にある主張をして来る人にモヤッとした場合は、「この人は簡単そうに言っているけど実は嫉妬感情に打ち勝って今があるのかもしれない」と思うことにしました*1

それはそれとして、他人の足を引っ張って喜ぶ人は普通に悪人なのであまりそういった人に関わらないような人生にしたいです。

*1:レアケースでそういった感情が本当にない変人

『Java本格入門』で、Javaの知見を体系的に濃縮する

Javaのプログラムを書いているとき、「これはベストな書き方なのか?」という疑問は常にあると思います。ネットで調べる、レビューを受けるといった、確認方法はいくつかあると思いますが、その一つが本書になると思います。

Java本格入門 ~モダンスタイルによる基礎からオブジェクト指向・実用ライブラリまで

Java本格入門 ~モダンスタイルによる基礎からオブジェクト指向・実用ライブラリまで

表紙の情報量が非常に多いのが特徴です。

対象読者層

「はじめに」に書いてあるのでほぼ合っていると思います。

オススメな人

  • Javaをある程度お仕事で書いてきた

  • 体系的に学びなおしたい

お仕事で書いてきたというのは、実際に稼働するコードを書いた。また、他人の書いたコードを読んだり直したりしたことがある、という意味です。

向かない人

プログラミング経験がほとんどない人

特徴

トピックは多岐にわたりますが、全般的にめちゃくちゃ絞り込んであります。「本格入門」であって入門書ではないので、ある程度文法を分かっている前提で進みます。

また、筆者のこれまでの経験を生かして、「結局どうすればいいか」が書いてあります。

例えば、インタフェースのデフォルト実装をとりあげます。

抽象クラスとどのように使い分けるのかという疑問について、「インタフェースのデフォルト実装は基本的に使わなくてよい」と簡潔に答えています。

理由としては、

デフォルト実装は、Javaの「過去のバージョンとの互換性*1」のために生まれた

という、Javaの歴史を感じるものになっています。納得感のある説明になっていると思います。

デザインパターン

GoFデザインパターンは23種類もあって身に着けるのが大変ですが、本書では9つに絞って紹介しています。

結城『デザインパターン入門』に比べると、書中ですべてのコードを載せているわけではありませんが、実際に使いそうな例になっています。

Abstract Factoryパターンでの呼び出し側のコードは以下の通りです。

public class SampleMain {
    public static void main(String... args) {
        String env = "PostgreSQL";
       
        Factory factory = createFactory(env);
        Connection connection = factory.getConnection();
        Configuration configuration = factory.getConfiguration();
    }

    private static Factory createFactory(String env) {
        switch(env) {
            case "PostgreSQL":
                return new PostgreSQLFactory();
            case "MySQL":
                return new MySQLFactory();
            default:
                throw new IllegalArgumentException(env);
        }
    }
}

ただ、個別のパターンの解説の詳しさは、結城本のほうが上回っています。例えば、このパターンでは「工場」を増やすのは簡単です。OracleFactoryは既存の実装に影響を与えずに追加できます。一方、新しい「部品」、HogeSettingsを追加しようとすると、すべての既存の「工場」に影響が出てしまうので大変です。そのような説明が結城本に記載されています。

本書でも記載はありますが、個人的には結城本を読んで初めてちゃんと理解できた印象です。「わかっている人にはこれくらいの説明で十分」という感覚ですかね。

記載のないもの

後半で、デザインパターンや各種ライブラリの説明がありますが、基本的には各クラス内で、どのように書くべきかという説明が中心になっています。設計的な話はあまりないのかな*2という印象です。

まとめ

ブログタイトルに「濃縮する」と書いた通り、コンパクトに必要な記載を詰め込んでいるのが本書の良いところだと思います。

余談ですが、私は6年くらい前に筆者たちが所属するアクロクエストテクノロジー株式会社に1日インターンに行ったことがあります。当時は1ミリもプログラムを書いたことがなかったはずなのになんで行ったのか全く覚えていませんが、こういった形でまた巡り合うことになるとは、不思議な縁を感じます。

*1:具体的には7と8

*2:一定レベル以上のクラス設計は本書の対象外という記載もある

楽しいリモートワーク

リモートワーク(テレワーク)*1を1週間連続で実施したので体験まとめ記事です。

なお、前提として私は一人暮らしです。

背景

リモートワークを推奨する期間があり、それにのっかりました。

また、その期間では同僚たちが会社からいなくなるので、自分も出勤してもしょうがないかなという雰囲気でした。

事前準備・リモートワーク環境構築

やると決めたら色々必要な準備をこなしました。

各種設定が必要でしたが、申請とかで待たされることは特になく、スムーズに進みました。

最終的にPCを家に持って帰って準備万端です。

やったこと

基本的には家で一人でコーディングしていました。入社して間もないので、分からないことができたらslackのオープンなチャンネルでメンション飛ばして聞いていました。

また、slackでの電話会議もありましたが、特につつがなくできており*2、その点で特に効率の低下を感じることはありませんでした。

これまで「困ったらslackで聞く」ということをしたことがなかったので、今回それが結構有効だと気づけたのが収穫です。

また、洗濯を初めとした家事がはかどりました。

感想

入社したばかりで出来ることが少ない自覚があったので、「仕事が全く進まなくなったらどうしよう…」という懸念がありました。しかし、周りのサポートもあり何とかなりました。

具体的には、次やることを決めるにあたっての的確なサポート、タスクの遂行時に「誰に聞いたらいいか」がハッキリしていたことです。

あまり聞きすぎて邪魔になってはいけないと思いますが、適当なタイミングで聞けていたと思います。

ちなみにタイミングに関しては、相手の状況がまるでわからないので、対面で尋ねるような機を伺う*3ことをせず、素直にメンションを飛ばしていたような気がします。

何より通勤時間がゼロになったので、その分寝る時間が増えたのが良かったです。

今後も頃合いを見てリモートワークをしたいと思います。

*1:違いはないものと思っています。現職ではテレワークと言われていますがリモートワークの方が広まっている印象なのでそうします。

*2:画面共有も問題なし

*3:席に戻ってきたら聞こう、など

レビュー『データは騙る』

読書レビューです。

データは騙る: 改竄・捏造・不正を見抜く統計学

データは騙る: 改竄・捏造・不正を見抜く統計学

邦題のイメージからは、統計学を使って不正を見抜くんや!みたいな印象を持ちますが、実際はデータの間違った使い方を指摘する側面のほうが強いです。

ちなみに原題は『Standard Deviations*1』です。邦題の『データは騙る』の方が少し上回っているかと思います。

最近の懸念

最近、成功者が「成功した人は○○している」と言うたびに「はいはい生存バイアス」と返される流れをよく見る気がします。なんとなく、思考停止の感じが出てきて嫌だなと思ったので、妥当な指摘かどうか確認したく、本書を手に取りました。

読後に冒頭の問いを振り返ると、「まあ妥当な指摘なんじゃないですかね」という結論になりました。

以下、学びになったことを記載します。

最も難解な「自己選択バイアス」

私の言葉で自己選択バイアスを説明すると、Aという選択をした人としなかった人とを比較して何かしらの差異を述べようとしたとき、実際は別の要素がその違いに影響を及ぼしているという誤解のことを指します。

本書中の例を以下に引用します。

「大学を卒業した人間は、退学した者に比べて平均で五四パーセント多く稼いでいる。したがって、卒業証書には経済的な意味がある」ここにも自己選択バイアスが見られる。大学に行くことを選択し、卒業できるように一生懸命に勉強した学生は、途中で大学を辞めた人とはさまざまな面で違ってくるのではないだろうか。

私が、なぜ難解としたかというと、実際に自己選択バイアスを見抜き、その裏側にある真因を指摘するのは難しいと思ったためです。特に、自分にとって違和感のない主張に対してはすんなりと受け入れてしまうためにさらに難しくなると思います。

自己選択バイアスに敏感になれればいいのですが、それが難しい場合にも他者の指摘を受け入れて自分の固定観念を見直せればいいなと思いました。

(参考:自己選択の説明)

自己選択バイアス(じこせんたくばいあす)とは | アンケートQ

平均への回帰

スポーツのような実力に対して、結果がばらつく場合、ある年度でトップの成績を収めた人は、その前後の年度ではそこまで優れた成績でないことが多いとのこと。

この場合、平均への回帰は、「真の実力への収束」といってもいいと思います。

読者の想定レベルが低い?

本書では、時折常識的な指摘すぎてアホかと思ってしまうことがあります。例えば、グラフについての章を取り上げます。

ここでは、「縦軸や横軸の目盛りは省略してはならない」と大真面目に書いていました。

意外とデータに対する世間のリテラシーが上がっているのか、もしくは自分の周囲だけなのか、どちらにしてもだいぶ簡単な内容だなと思いました。

常識の力、厄介さ

本文中で、常識的に考えればおかしいような主張が論文として世に出ていた事例が紹介されています。例えば、「超能力が存在する」「特定のアルファベットから始まる人は早死にする」など。

そして、筆者はそれらの主張のもととなる論文・データがおかしい理由を丁寧に*2説明しています。代表的な理由としては、自分の主張を支持するデータを抜き出したためです。

筆者は、自分の持つ常識を大事にしようと述べています。

一方で、気をつけるべきこととして、今回読んでいて正しかったのは自分の常識ですが、これが間違っていると突きつけられるときがかならず来るということがあります。

そのとき、自らの考えに固執せず、柔軟に変えられるかどうかが大事だと思います。

お役立ちの19章

本書は全19章とボリューム盛りだくさんですが、最後の19章はこれまでの振り返りになっています。自己選択バイアスや、誤ったパターン化など、重要だけど難しい概念を思い出せます。

まとめ

爆発的に増大しているデータや分析に対して、どう判断したらいいかわからなくなっている人にはいいと思います。当レビューで取り上げた以外にも、役立つ概念がたくさんあります。

*1:標準偏差

*2:若干くどいレベル

目標設定、好きなこと、得意なこと、なりたい姿について

今日はふわっとしたことについて考えます。タイトルにある4点です。

目標設定

会社員をやっていると目標設定を課せられることがよくありますが、私はこれが好きではなく、苦手です。

なぜなのか考えてみると、いくつか理由を思いつきました。

  • どれだけの達成可能性があるかわからないまま目標を立てがちだから (目標を立てた段階で、それがどれくらい難しいことなのか判断つかない)

  • 目標に対して、達成したかどうかの判断基準がイマイチだから

    • 計測可能でない
    • 目標に関係ない
  • 評価に関わってくるから

しかし、こうも考えています。これが得意になれば、好きになるのでは?と。

評価についてはそんなに気にしなくていいし、定量的な目標は、うまく考えれば立てられるような気がしています。

好きなこと

自分の好きなことはなんだろう、と考えると、

  • 1日10時間寝ること
  • 散歩すること
  • カフェ読書

と、仕事に関係ないものが並びます。今自分が100億円持っていたら上記のような生活を送ります。

残念ながらそんなお金はないので仕事をしています。

仕事に限定して好きなことを考えると、現段階だとやや曖昧だなと感じています。

そこで、以下の手法をとってよりクリアにしていこうと思います。

  1. 好きなこと(と思われるものも含む)を書き出す。
  2. しばらく色々なことに取り組み、実際に好きだったか記録する。その際、今まで取り組んでいないことにもチャレンジすることと、すぐに諦めずにしばらく続けることを意識する。
  3. 振り返って1.の作業をもう一度やる。以降繰り返し。

2.を補足すると、仕事において成長していくためにはチャレンジして継続していく姿勢が不可欠と思いますが、自分の場合それが結構エネルギーを要するもので、意識的にやっていかないとできないと思っています。

得意なこと

「好きなことより得意なことを仕事にしたほうがいい」という言説を聞きます。

得意なことも、好きなこととほぼ同じ手順で発見できると思っています。

ただ、一つ追加してやっておきたいことがあります。

それは他人の得意な事柄を見つけることです。他人の得意不得意について考えることで、自分のそれについても考えやすくなると思われます。

なりたい姿

仕事に限定すると、「スタンダードなサーバーサイドエンジニア」が今のなんとなくのイメージです。どうすればなれるのかというと、

コードが書ける、アーキテクチャフレームワークが理解できる、設計ができる、チームワークができる、アプリケーションを作るにあたって重要な概念を理解している*1、そんなところでしょうか。

まとめ

これら4つについて、定期的に考えていくと良さそうです。無から構築するわけではなく、最近あった出来事について、自分は何をしたか、何を思ったかを記録してそこから考えると、より正しい答えが見えてくるような気がします。

*1:パフォーマンス、セキュリティ、ネットワークとか