Sunny

ボルダリングをはじめて3年目に突入した2017年、 スポドリのコンペでいい結果を出してからは色んなジムのコンペに参加したり、 外岩で3段落としたりいい1年でした。

http://blog.arktks.com/post/137158258901/ボルダリング年表

に続き今回も1年であった出来事をざっくりとまとめてみる。

2017/1 前年12月に忍者クライマー返し2段を落としたので、2017年は3段落とす目標を立てる

結婚したので週4、5から週3に減らして質を高める

そのためスポドリの月会員をやめて他のジムも登る

2017/3 ボルダリングメインでinstagramをはじめる

https://www.instagram.com/arktks/

2017/3/25 御岳の忍者岩、デッドエンド岩以外を触りはじめて↓を落とす

鵜の瀬岩の「立ち鵜1級」「鵜の瀬バリエーション初段」

ロッキー岩の「エゴイスト初段」

2017/4//16 御岳の「砂箱1級」を落とす

ロッキー岩の「遙エゴイスト2段」触るも完登ならず、、

2017/4/22 ロッキー岩リベンジ！

「遙エゴイスト2段」「遙2段」落とす

2017/4/29 ロッキー岩の「in tokyo3段」に挑戦するも絶望、、

ロッキー岩にある「炎初段」落とす

2017/5/4 はじめて品川ロッキーに行く

1級7つ、初段1つ落として気持ちよく帰る。

この月から毎月最低1回は品ロキに通うことになる

今更だけどBCAAを摂取するようになる。何でもっと早く取り入れてなかったんだろ、、

2017/6/17 スポドリのコンペで予選1位、決勝2位！

前年は上級カテゴリーの18位？くらいだったので成長を感じた

前月からはじめたロッキー通いでオブザベやオンサイトの力がついた気がする

2017/7/18 グリーンアローのコンペで予選と決勝ともに2位！

100人以上いたのに知り合いが誰もいない完全アウェイ笑。グリーンアロー新小岩店はいいジム

2017/9/18 InBodyで体成分を調べたら上半身の筋肉量が「並」と診断される、、　

上半身を鍛える筋トレをこの頃からはじめる＆今までソイプロテインしか飲んでなかったけどホエイも摂取するように

2017/9/23 Apexのコンペで予選2位、決勝7位、、、

決勝課題の強度が高すぎて全く歯が立たず。自分には無理と思った課題も積極的に挑戦することを決意

2017/10 スポドリで村井隆一さんによる月1の講習がはじまる

講習というよりほぼセッションだけど、たまに村井さんが登るムーブが凄すぎてテンションが上がる

品ロキで初の2段登る！

2017/11 9月頃からはじめた上半身筋トレの効果を感じ始める。上半身のブレが少なくなった

そろそろ外岩に行かなきゃだったけど、週末になると必ず雨になる、、

それに加えて右の背中あたりを痛めて1ヶ月くらい全力で登れなくなる

2017/12/10 忍者岩にある「蛙3段」登る！

今シーズン3回目にて無事完登。虫は来年かなあ

この時右手の小指に肉芽が出来て2週間くらいまともに登れなくなる、、

早速、今のmackerel のカスタムダッシュボード載せてみる

※ グラフはそれぞれ 1時間 / 1日 / 1週間 の集計のものを表示 ※ リリース前なのでデータが少ない

前提

Java8 / Spring Boot1.5 / Gradle3.3 / Actuator を利用

Mackerel は Standard プランにアップグレード

Free プランではカスタムダッシュボード使えない、サービスメトリック数は5まで

Standard プランはサービスメトリック数は200まで

参考サイト

http://qiita.com/kawasima/items/b203f789d8b6bb23a575

https://github.com/kawasima/metrics-mackerel

https://mackerel.io/ja/docs/entry/howto/dashboard

背景

mackerelの導入は簡単だけど、JVMのメトリクスを取得できない

mackerel-plugin-jvm使うとヒープ使用状況とGCの頻度は取得できるがスレッド数は取得できない

APIのレスポンスタイムを取得してどのAPIが遅いのか把握したい

できればグラフ化してすぐ分かるように

上記を監視目的で導入しているmackerel内で完結させたい

手順

actuator の導入

actuatorを使うとシステムの状態やメトリクスを確認することができる。 導入するには Gradle なら build.gradle に下記を追記するだけ

dependencies { compile("org.springframework.boot:spring-boot-starter-actuator") }

actuator で他に何ができるかは下記を参照 https://docs.spring.io/spring-boot/docs/current/reference/html/production-ready-endpoints.html

今回は /metrics にアクセスした際に取得できるパラメータを mackerel で表示させてみる

https://docs.spring.io/spring-boot/docs/current/reference/html/production-ready-metrics.html

※ 背景で挙げた項目が取得できる他、各API のコール回数も取得できる模様

metrics-mackerel の導入

actuator の /metrics で取得できるメトリクスを mackerel に送ることができるプラグイン。ありがたや build.gradle に下記を追記して、

dependencies { compile('net.unit8.metrics:metrics-mackerel:0.1.1') }

Config 用のクラスを作成して完了

package com.xxx.config; import com.codahale.metrics.Gauge; import com.codahale.metrics.MetricRegistry; import com.xxx.model.enums.Env; import net.unit8.metrics.mackerel.MackerelReporter; import net.unit8.metrics.mackerel.MackerelSender; import org.springframework.beans.factory.annotation.Autowired; import org.springframework.beans.factory.annotation.Value; import org.springframework.boot.actuate.endpoint.SystemPublicMetrics; import org.springframework.boot.actuate.metrics.Metric; import org.springframework.context.annotation.Configuration; import javax.annotation.PostConstruct; import java.util.concurrent.TimeUnit; @Configuration public class MackerelConfig { @Autowired private MetricRegistry registry; @Autowired private SystemPublicMetrics systemPublicMetrics; @Value("${mackerel.apiKey}") private String apiKey; @Value("${mackerel.serviceName}") private String serviceName; @Value("${common.env}") private String env; @PostConstruct public void initialize() { // 本番環境だけメトリクスを取得 if (!Env.isLive(this.env)) { return; } for (final Metric> metric : this.systemPublicMetrics.metrics()) { final Gauge metricGauge = () -> metric.getValue().longValue(); String name = metric.getName(); if (!name.contains(".")) { name += ".total"; } this.registry.register(name, metricGauge); } final MackerelSender sender = new MackerelSender(this.serviceName, this.apiKey); final MackerelReporter reporter = MackerelReporter .forRegistry(this.registry) .build(sender); reporter.start(1, TimeUnit.MINUTES); } public void setApiKey(final String apiKey) { this.apiKey = apiKey; } public void setServiceName(final String serviceName) { this.serviceName = serviceName; } }

※ 事前に application.yml に mackerel のapiKeyとserviceNameを定義しておくこと

これだけで、mackerel の Services -> サービスメトリック にグラフが出ます

mackerel でカスタムダッシュボードを作成

ここまでで目的のグラフは表示されるようになったが、 そんなに見たくないグラフもたくさん表示されてしまうので、 必要そうなグラフだけが表示されるカスタムダッシュボードを作成する。

https://mackerel.io/ja/docs/entry/howto/dashboard

グラフの右上にシェアボタンがあるので、そこからiframe タグをコピって、 カスタムダッシュボード作成画面に下記のように貼り付け。

<iframe src="https://mackerel.io/embed/orgs/xxx/services/xxx-live?graph=gauge.response.api.v1.%2a&period=1h" height="200" width="400" frameborder="0"></iframe> <iframe src="https://mackerel.io/embed/orgs/xxx/services/xxx-live?graph=gauge.response.api.v1.%2a&period=1d" height="200" width="400" frameborder="0"></iframe> <iframe src="https://mackerel.io/embed/orgs/xxx/services/xxx-live?graph=gauge.response.api.v1.%2a&period=1w" height="200" width="400" frameborder="0"></iframe>

注意点

actuator のデフォルト設定だと、/metrics の他にシステムの状態が表示された、たくさんのエンドポイントが"/"直下のパスにできてしまう。 https://docs.spring.io/spring-boot/docs/current/reference/html/production-ready-endpoints.html 本番ではこれらのパスは一般公開してはならず、ラボからのアクセスのみに制限したいが、 1つ1つ制限するのはめんどうなので、下記を参考にエンドポイントのパスはまとめる

management: contextPath: /manage

https://docs.spring.io/spring-boot/docs/current/reference/html/production-ready-monitoring.html

https://booth.pm/ja/items/392260

第1章 DDDってなに？

p.2 「DDDとは」

> DDD は Domain Driven Design の略で、日本語ではドメイン駆動設計と訳されます。ドメ イン駆動設計はソフトウェア開発手法であり、ソフトウェアモデルを設計する手助けとなる手法です。

p.3 「DDDでは何をする？」

> DDD では 開発者とドメインエキスパートが協力して、ドメインを反映したモデル（ドメイ ンモデル）を作り上げます。

> ドメインとは何か、詳しくは後の章で解説しますが、簡単にいうとソフトウェアを適用す る対象領域です。たとえば会計ソフトを作っているとしたら、そのソフトウェアのドメインは会計業務です。

> ドメインエキスパートとは役職の名前ではありません。今扱っている業務について誰より もよく知っている人、少なくとも自分よりよく知っている人はドメインエキスパートです。次

p.4 「ドメインを反映したモデル」

> ドメインを反映したモデルとは、ドメインを構成する物・概念・振る舞い・関係性を表現したものです。

p.4 「DDDをすべき理由」

> • ドメインエキスパートと開発者を同じ土俵に乗せることで、プログラマーの視点だけで なく業務側の視点も踏まえたソフトウェアを作れるようになる

> • そのソフトウェアに関して理解しているのが一部の人（たいていは開発者）たちだけと いう状況をなくすことができる

> • ドメインエキスパートとソフトウェア開発者、そしてソフトウェアそのものとの間で、一切の通訳が不要になる

> • 設計がコードであり、かつコードが設計でもある

p.5 DDDの要素

> • 戦略的設計 >　　– ユビキタス言語 >　　– 境界づけられたコンテキスト >　　– コンテキストマップ > • 戦術的設計 >　　– エンティティ >　　– 値オブジェクト >　　– サービス >　　– レイヤー化アーキテクチャ

> 戦略的設計をやらずに戦術的設計だけをつまみ食いしても、それは完全な DDD ではありません

第2章 ユビキタス言語ってなに？

p.11 「ユビキタス言語とは」

> ユビキタス言語は DDD を構成する要素のひとつで、DDD の実践には必須です。ユビキタス言語とは、ドメインエキスパートやソフトウェア開発者を含めたチーム全体 で作り上げる共通言語のこと。

> ユビキタス言語は名前集ではありません。ユビキタス言語には振る舞いも含まれます。名 詞だけでなく形容詞や動詞も出てこないとおかしいです。

p.12 「ユビキタス言語を見つけるには」

> • ドメインエキスパートの使っている用語やフレーズを観察する > • 業務のゴール（ユースケースやシナリオと呼んでいることもある）を反映する用語やフレーズを観察する > • 既存のドキュメントを取りまとめて用語やフレーズを見つけ出す

p.13 「変化し続けるユビキタス言語」

> ユビキタス言語を用語集 化しようとドキュメントを作るのは現実的ではありません。ある用語に説明が必要だと思っ たときは、用語集を作るのではなくそれを表すソースコード上のモデルにコメントを書くほうが現実的です

p.13 「ユビキタス言語の適用範囲」

> チームでの会話・ドキュメント・ソースコードなど、あらゆるところでユビキタス言語を利用します。

p.14 「ユビキタス言語の確立」

> • 同じものを表す用語が複数ある > • 概念はあるのに名前がない > • ビジュアルはあるのに名前がない

第3章 ドメインモデル

p.17 「ドメインモデルとは」

> ドメインモデルはドメインを適切に反映したモデルです。コードに落とし込む前の、より概 念的なモデルです。名前や関係性、振る舞いが反映されており、チームメンバー全員が同じも のを思い浮かべ、同じ解釈をするものです。

> • ドメインモデルはドメインを反映したもの > • ソフトウェアモデルはドメインモデルを表現したもの > • コード上のモデル（オブジェクトモデルなど）はソフトウェアモデルを実装したもの

p.21 「ドメインモデル貧血症」

> ドメインモデルと呼んでいるものが実はただの getter/setter しかない値を保持するだけの オブジェクトであったり、ドメインモデル（と呼んでいるもの）を利用する側のコードがほと んどのロジックを抱えているような状態を ドメインモデル貧血症といいます。

第4章 境界づけられたコンテキストって？

p.25 「ドメインとは」

> 組織が行う事業やそれを取り巻く世界のことだ。事業が市場を定義して、プロダクトや サービスを販売する。組織にはそれぞれ、自分たちの対象とする領域についてのノウハ ウや物事の進めかたがある。その領域、そして業務を進めていくための方法が、ドメインだ。

p.26 「サブドメイン」

> ソフトウェアの価値をもたらす部分、ビジネスの問題を解決する部分がコアドメインです

> 支援サブドメインと汎用サブドメインの違いは、業務に不可欠なものかどうかという点で す。いずれも業務をうまく進めるために重要ですが、業務上特別なことをしているのが支援サ ブドメインで、していないのが汎用サブドメインです。

p.28 「境界づけられたコンテキストとは」

> ドメインモデルはユビキタス言語で構成されていますから、ドメインモデルは特定の境界づ けられたコンテキストに属することになります。つまり、境界づけられたコンテキストとは、 ドメインモデルを適用する範囲であるともいえます。

p.32 「食材管理アプリの境界づけられたコンテキスト」

> 境界づけられたコンテキストごとにドメインモデルを作るということは、レシピ検索部分を 別のシステムに入れ替えることになっても、賞味期限管理のドメインモデルは影響を受けない ということです。

第5章 コンテキストマップ

p.37 「コンテキストマップとは」

> コンテキストマップは、複数の境界づけられたコンテキストとそれらの関係性を描いたもの です。これはプロジェクトに関わる全員で共有、理解するためのものです。 > コンテキストマップを作る際に特に気をつけるべきことは、境界づけられたコンテキストの 名前をユビキタス言語の一部にすることです。

第6章 コンテキストマップを活用する

https://www.amazon.co.jp/dp/4873117607/

第8章 監視

p.183

> 複数のサービスを監視して、複数のログファイルを調べる必要があり、ネットワーク遅延が原因で問題を引き起こす場所が複数あります。 > 小さなものを監視し、それを集約して全体像を見るのです。

p.188 「複数サービスにわたるメトリックの追跡」

> サービスの新しいインスタンスを頻繁にプロビジョニングするので、システムで新しいホストからメトリックを簡単に収集できるようにしたい

p.191 「合成監視」

> 合成トランザクションを使ってこのようなセマンティック監視を実行した方が、低水準メトリックに対して警告するよりも、システム内の問題に対するはるかに優れた指標となる。

p.192 「相関ID」

> 最初ｎ呼び出しを行うときには、その呼出のGUIDを生成します。そして、このIDは後続のすべての呼び出しに渡され、ログのレベルや日付といった要素と同様に構造化された方法でログに書き込まれます。すると、適切なログ集約ツールを使ってシステム内でそのイベントを追跡できるようになります。

p.197 「まとめ」

> 最低でもインバウンド応答時間を追跡します。これが終わったら、続いてエラー率、そしてアプリケーションレベルのメトリックに取り掛かります。 > すべての下流のレスポンスの健全性を追跡します。最適でも下流呼び出しの応答時間を追跡し、できればエラー率も追跡します。 > メトリックを収集する方法と場所を標準化します。 > 可能なら標準的な場所に標準形式でログを記録します。すべてのサービスが異なる形式を使ったら、集約が面倒になってしまいます。 > 相関ID利用の標準化を積極的に検討します。

第9章 セキュリティ

p.199 「認証と認可」

> セキュリティにおいては、認証はある関係者が確かに名乗っている本人であることを確認するプロセスです。

p.200

> 認可は、プリンシパルとプリンシパルに許されている動作をマッピングするメカニズムです。プリンシパルを認証するときに、私達はプリンシパルに何を実行させるべきかを判断するための情報を与えます。

p.204 「サービス間の認証と認可」

境界内のすべてを許可する

> 境界内からのあらゆるサービス呼び出しを暗黙的に信頼できるものとみなします。 > 攻撃者がネットワークに侵入すると、典型的な中間者攻撃に対する防御がほとんどありません。

HTTP(S)ベーシック認証

> サーバは独自のSSL証明書を管理する必要があり、複数マシンを管理する場合は問題になります。独自の証明書発行プロセスを採用している組織もあり、それが余計な管理上および運用上の負担になります。 > SSL経由で送信されるトラフィックを、VarnishやSquidといったリバースプロキシでキャッシュできないという欠点があります。

SAMLやOpenID Connectの使用

> ベーシック認証と同様に、認証情報を安全に格納する必要があります。 > SAMLではクライアントの実装が大変な作業になります。

クライアント証明書

> 単にサーバ側証明書を使用する場合よりもさらに面倒なことです。多数の証明書を作成して管理するという基本的な問題だけではありません。むしろ、証明書自体に関するあらゆる複雑さを伴うため、完全に有効なクライアント証明書だと思われる証明書をサーバが受け付けない理由を診断しようと、多くの時間を費やすことになります。

APIキー

> APIキーにより、サービスは呼び出し元を特定し、実行できることに制限を設けることができます。この制限は、単にリソースへのアクセスを与えるだけでなく、特定の呼び出し元の速度制限などの処理にも拡張して他のユーザのサービス品質を保護できます。

第10章 コンウェイの法則とシステム設計

p.223

> システムを設計するあらゆる組織は、必ずその組織のコミュニケーション構造に倣った行動を保つ設計を生み出す。

p.226 「コミュニケーション経路に適応する」

> システム開発に携わる人々の間の地理的境界は、サービスを分解すべきタイミングを示す優れた指標であり、一般に変更のコストを低く抑えられる1つの場所にいる単一チームにサービスの所有権を割り当てるようにすべきです。

p.227 「サービスの所有権」

> 所有権は要件の特定からアプリケーションの構築、デプロイ、保守まで、サービスのあらゆる面に及びます。 > 単一チームがアプリケーションのデプロイと保守の責任を負うと、デプロイしやすいサービスを作成しようと思います。つまり、投げ出す相手がいなければ、「何かを投げ出す」心配はなくなります。

p.228 「フィーチャーチーム」

> 誰もがすべてのサービス、すべてのコードを変更できます。すると、サービス管理者の役割はずっと複雑です。残念ながら、このパターンを採用している場面で管理者が機能しているのをほとんど見たことはありません。 > 技術ドメインではなくビジネスドメインに倣ってモデル化されたサービスです。そして、あるサービスを所有するチームがビジネスドメインに合わせて構成されていると、チームは顧客中心の姿勢を維持でき、サービスに関連するすべての技術を全体的に理解して所有するので、より多くの機能開発をやり遂げられる可能性が高くなります。

第11章 大規模なマイクロサービス

p.238 「障害はどこにでもある」

> サーバは故障することがあるという事実にシステムで対処できることがわかっていれば、そもそも障害の対処に悩まされる理由があるでしょうか。1台のノードの回復性を心配しすぎるよりも、Googleが行っていたように安価なコンポーネントを備えた裸のマザーボードを使えばよいのではないでしょうか。

p.242 「アーキテクチャ上の安全対策」

> 問題は、下流システムが遅いために、すべてのワーカがタイムアウトになるのにしばらく時間がかかていたことでした。 > タイムアウトを適切に構成し、異なる接続プールを分離するための隔壁を実装し、そもそも不健全なシステムに呼び出しを送らないようにするためにサーキットブレーカーを実装しました。

p.244 「アンチフラジャイルな組織」

> 障害を発生させ、障害に備えて構築することで、Netflixはスケーリングに優れ、顧客のニーズをより適切にサポートするシステムになるようにしています。

p.245 「タイムアウト」

> すべてのプロセス外呼び出しにタイムアウトを設定し、すべてに対するデフォルトタイムアウトを指定します。タイムアウトが発生したときをロギングし、何が起こったかを調べ、それに応じて変更します。

p.245 「サーキットブレーカー」

> サーキットブレーカーがある場合、下流リソースへの特定の数のリクエストが失敗すると、サーキットブレーカーが落ちます、。サーキットブレーカーが落ちてる間は、すべてのリクエストが失敗します。特定の時間の経過後、クライアントはリクエストを送信して下流サービスが復旧しているかを確認し、十分に健全なレスポンスを得たら、サーキットブレーカーをリセットします。

p.247

> サーキットブレーカーが落ちている間は、いくつかの選択肢があります。その1つは、リクエストをキューイングして後でリトライすることです。ユースケースによっては、特に非同期ジョブの一環として処理を行っている場合には、これが適しているでしょう。しかし、この呼び出しを同期呼び出しチェーンの一部として行っている場合には、おそらくすぐに失敗する方がよいでしょう。

p.248 「隔壁」

> 下流接続ごとに異なる接続プールを使うべきでした。ある接続プールを使い果たしても、他の接続は影響を受けません。すると、下流サービスの動作が遅くなり始めても、その接続プールだけが影響を受け、他の呼び出しを通常通り進めれます。

スケーリング

p.251 「より大きくする」

> 垂直スケーリングと呼ばれるこのようなスケーリングは、コストが高く付きます。他にも、このようなスケーリングは、サーバが1台しかない場合にはサーバの回復性をあまり改善しないという問題があります。

p.252 「リスクの分散」

> （停止が複数のサービスに影響を与える）1台のホストに複数のサービスを配置しないようにすることです。

p.254 「負荷分散」

> SSLターミネーションでは、ロードバランサへの受信HTTPS接続をHTTP接続に変換します。以前はSSL管理のオーバーヘッドは非常に大きかったので、ロードバランサにこのプロセスを対処させるのはとても有益でした。最近では、インスタンスを実行する個々のホストの設定を簡素化するためにも、これを使います。

データベースのスケーリング

p.258 「読み取りのためのスケーリング」

> もう1つのモデルはリードレプリカです。サービスでは書き込みをすべて1つのプライマリノードに向けても、読み取りを1つ以上のリードレプリカに分散できます。 > レプリケーションが完了するまでは読み取りで陳腐化したデータが見えてしまう場合があります。最終的には、読み取りで整合性のあるデータが見えるようになります。このような設定を結果整合性があるといい、一時的な不整合に対処できれば、これはシステムをスケーリングを助けるとても簡単で一般的な方法です。 > 現在ではまずキャッシングを目指すことをお勧めします。キャッシングの方が性能をもっと大幅に改善でき、大抵は労力も少なくて済みます。

p.259 「書き込みのためのスケーリング」

> シャーディングでは、複数のデータベースノードがあります。書き込むデータに何らかのハッシュ関数を適用し、その結果に基づいてデータを送信する場所を決めます。 > 書き込み用のデータベースのスケーリングはとても面倒で、さまざまなデータベースの機能に違いが出てきます。

p.260 「共有データベースインフラ」

> システムの実行に必要なマシン数を減らすという観点でとても便利ですが、重大な単一障害点を導入してしまいます。このデータベースインフラがダウンしたら、一度に複数のマイクロサービスに影響を与え、壊滅的な停止を引き起こす可能性があります。

キャッシング

p.262 「クライアント側、プロキシ、サーバ側のキャッシング」

> クライアント側のキャッシングはネットワーク呼び出しを大幅に減らすことができるので、下流サービスの負荷を減らす一番の近道の1つです。この場合、クライアントがキャッシングの振る舞いを管理しており、キャッシング方法を変更したい場合に、その変更を多数のコンシューマに展開するのが困難なことがあります。陳腐化したデータの無効化も面倒です。

> プロキシキャッシングでは、クライアントとサーバの両方にとってすべてが不透明です。多くの場合、これは既存システムにキャッシングを追加するとても簡単な方法です。一般的なトラフィックをキャッシュするようにプロキシを設計すると、複数のサービスをキャッシュすることができます。

> サーバ側のキャッシングでは、クライアントにとってすべてが不透明です。サービス境界内やサービス境界近くでのキャッシュでは、データ無効化のような検証やキャッシュヒットの追跡や最適化が容易になります。複数の種類のクライアントがある場合には、サーバ側のキャッシュが性能を改善するための一番の近道になるでしょう。

p.265 「回復性のためのキャッシング」

> クライアント側のキャッシングでは、下流サービスが利用できない場合、クライアントは陳腐化している可能性のあるキャッシュされたデータを使えます。また、リバースプロキシなどを使って陳腐化したデータを提供することもできます。

p.266 「簡潔に保つ」

> キャッシングが多いほど、新鮮なデータを入手するのが難しくなります。キャッシュが得策と考えている場合には、簡潔に保って1つだけにすることを堅持し、追加する前には慎重に検討してください。

p.269 「CAP定理」

> CAP定理は、分散システムに互いにトレードオフとなる3つの事項があることを示しています。それは、整合性、可用性、分断耐性です。具体的に言うと、この定理は故障モードではこの中の2つを得ることを示しています。 > 整合性は、複数のノードで同じ答えが得られるというシステム特性です。可用性は、すべてのリクエストがレスポンスを受け取るという意味です。分断耐性は、システムの部分間の通信ができないことに対処できるシステムの能力です。

p.271 「整合性を犠牲にする」

> システムは両方のノードがリクエストに対処できるという点で引き続き利用可能です。このような分断にもかかわらずシステムは動作を続けていますが、整合性が失われています。多くの場合、これはAPシステムと呼ばれます。

p.271 「可用性を犠牲にする」

> 整合性を保証できないので、リクエストへのレスポンスを拒否するしかありません。つまり、可用性を犠牲にするのです。システムに整合性と分断耐性があり、CPとなります。このモードでは、サービスは、分断が修復されデータベースノードを再同期できるまで機能低下する方法を導き出さなければなりません。

p.272 「分断耐性を犠牲にするか」

> システムに分断耐性がなければ、ネットーワーク上で動作できません。つまり、ローカルで動作する単一プロセスにならざるを得ません。CAシステムは分散システムでは存在しません。

p.274 「そして現実の世界」

> システム自体をどれほど整合性のあるものにしても、特に実世界のレコードを保有する場合には、発生するすべてを把握することはできません。多くの状況で結局はAPIシステムが適切になる主な理由の一つです。CPシステムは構築が複雑なことに加え、どちらにしてもすべての問題を修正することはできないのです。

p.275 「サービス検出」

> インスタンスを登録して「私はここにいます」というメカニズムを提供します。次に、サービスが登録されたら、そのサービスを探す方法を提供します。

p.275 「DNS」

> さまざまな環境でサービスのインスタンスを扱うときには、規約ベースのドメインテンプレートが効果的です。例えば、.musiccorp.com

p.281 「サービスの文書化」

> 理想的には、ドキュメントが常に最新のマイクロサービスAPIを反映し、サービスエンドポイントの場所がわかったときにこのドキュメントを簡単に閲覧できるようにします。

第12章 まとめ

p.285 「マイクロサービスの原則」

> 1.ビジネス概念に沿ったモデル化 > 2.自動化の文化の採用 > 3.内部実装詳細の隠蔽 > 4.すべての分散化 > 5.独立したデプロイ > 6.障害の分離 > 7.高度な観測性

p.289 「マイクロサービスを使用すべきでない場合」

https://www.amazon.co.jp/dp/4873117607/

第1章 マイクロサービス

p.3 小さく、かつ1つの役割に専念

> サービスの境界をビジネスの境界に合わせ、特定の機能のコードがある場所を明確にします。そして、このサービスが明示的な境界を念頭に置くようにすることで、サービスを大規模にしすぎてしまう衝動とそれに関連して生じるすべての複雑さを回避します。

主な利点

p.5 「技術異質性」

> サービスごとに異なる技術を使う決断をできます。すると、結局は最大工約数的になることが多い標準化された汎用的な手法を選ぶのではなく、ジョブごとに適したツールを選ぶことができます。

p.6 「回復性」

> システムのあるコンポーネントに障害が発生していても、その障害が連鎖しなければ、問題を分離してシステムの残りの部分は機能し続けることができます。

p.8 「デプロイの容易性」

> マイクロサービスでは、1つのサービスに変更を加えて、残りのシステムとは独立してデプロイできます。そのため、コードを迅速にデプロイできます。問題が生じた場合は、問題の原因である個別のサービスを迅速に特定でき、迅速なロールバックを簡単に実現できます。

他の分解テクニック

p.11 「共有ライブラリ」

> 技術的多様性が失われます。通常、ライブラリは同じ言語であるか、少なくとも同じプラットフォームで動作しなければなりません。次に、システムの各部をそれぞれ独立してスケールさせることが簡単ではなくなります。

p.12 「モジュール」

> 共有ライブラリと同じ欠点があります。新たな技術を使う能力や独立してスケールできる方法が厳しく制限されており、過剰に結合する統合テクニックへと向かってしまいます。

第2章 進化的アーキテクト

p.19 「区画指定」

> アーキテクトは、区画間で起こることに比べ区画内で起こることをそれほど心配する必要はありません。つまり、サービスが互いにどのように対話しているかを考えたり、システムの全体的な健全性を適切に監視できるようにすることに時間を費やす必要があるのです。

p.20 「原則に基づいたアプローチ」

> システム設計における判断はトレードオフです。マイクロサービスアーキテクチャには多くのトレードオフがあります。 > 実現したい目標に基いて意思決定を導く一連の原則とプラクティスを定めることです。

p.21 「戦略的目標」

> 戦略的目標は会社が目指す方向性であり、顧客を満足させる最善の方法だと確信できるものであるべきです。 > 戦略的目標は組織が目指す方向性なので、技術がその目標に一致するようにする必要があることです。

p.21 「原則」

> 原則とは、実行することを大きな目標に一致させるために作成した規則

p.22 「プラクティス」

> プラクティスは、原則を確実に実行する方法です。プラクティスは、タスクを実行するための詳細で実用的な一連の指針です。

必要な標準

p.24 「監視」

> サービスをまたがったわかりやすいシステム健全性のビューを作成できることが不可欠です。これはシステム固有のビューではなく、システム全体のビューでなければなりません。

p.24 「インターフェース」

> 少数の定義済みインターフェース技術は、新しいコンシューマを統合するのに便利です。標準の数は1つが適切です。

p.25 「アーキテクチャ上の安全性」

> 不適切な振る舞いのサービス1つで全関係者に損害を与えるわけにはいきません。サービスが不健全な下流呼び出しから適切に身を守るようにしなければなりません。

p.31 「チームの構築」

> 多くの責任を引き受ける前に個々のサービスを所有させることで開発者たちを向上させることは、各自のキャリア目標を実現させるための優れた方法であり、同時に責任者の負荷を軽減します。

第３章 サービスのモデル化方法

p.34 「疎結合」

> サービスが疎結合のときは、あるサービスを変更しても別のサービスを変更する必要はないはずです。マイクロサービスの本質は、システムの他の部分を変更する必要なしに、あるサービスを変更してデプロイできることです。

p.35 「高凝縮性」

> 関連する振る舞いは一緒にし、関連のない振る舞いは別の場所に配置したいでしょう。振る舞いを変更したいときに、１箇所で変更でき、その変更をできる限り早くリリースできるようにしたいからです。

p.37 「モジュールとサービス」

> 新規システムはよりモノリシックになるようにしてください。サービス境界を間違えるとコストがかかるので、新しいドメインに着手する際は事態が安定するまで待つのが賢明です。

p.42 「技術的境界」

> モノリシックシステムを地理的または組織的な線で分割するという考え方は全く合理的です。しかし、ここでは、このチームはビジネスに商店を当ててスタックを垂直方向に分割するのではなく、インプロセスAPIだったものを選び、水平方向に分割しました。

第４章 統合

p.45

> 適切な統合はマイクローサービスに関連する技術の最も重要な面だと私は考えています。統合を適切に行えば、マイクローサービスが自律性を保ち、全体とは独立して変更やリリースを行うことができます。

p.45 「破壊的変更を回避する」

> マイクロサービスが送信するデータに新しいフィールドを追加しても、既存のコンシューマに影響を与えないべきです。

p.48 「共有データベース」

> データベース統合では、強い凝集性と疎結合の両方を失います。データベース統合ではサービスがデータを共有しやすくなりますが、振る舞いの共有に関しては何も行いません。

p.49 「同期と非同期」

> リクエスト / レスポンスでは、クライアントがリクエストを発行し、レスポンスを待ちます。このモデルは同期通信に適していますが、非同期通信に使うこともできます。操作を開始してコールバックを登録し、操作が完了したときを知らせるようにサーバに依頼できます。

> イベントベースの連携では、状況が逆になります。クライアントがリクエストを発行して処理を依頼する代わりに、クライアントがある事態が起こったことを通知し、他社が何をすべきか知っていることを期待します。

p.50 「オーケストレーションとコレオグラフィ」

> オーケストレーションでは、オーケストラの指揮者のように中枢部に頼ってプロセスを推進します。コレオグラフィでは、バレエで周りの動きに合わせて自分の動きを決めるダンサーのように、システムの各部分にジョブを知らせ、詳細に対処させます。 > このオーケストレーション手法の欠点は、顧客サービスが中央監督機関になりすぎることです。

> コレオグラフィ手法では、代わりに顧客サービスに非同期でイベントを発行させ、「顧客を作成した」と通知することができます。 > 欠点は、明示的なビジネスプロセスが、システムには暗黙的にしか反映されなくなることです。

> 一般に、コレオグラフィ手法に向かう傾向が強いシステムの方が、疎結合で柔軟性があり、変更を受け入れることがわかっています。しかし、システム境界にまたがるプロセスの監視と追跡には追加の作業が必要です。

p.70 「クライアントライブラリ」

> クライアントライブラリに紛れ込むロジックが増えるほど、ますます凝集性が損なわれ、サーバへの修正を展開するのに複数のライブラリを変更しなければならないことに気づきます。また、クライアントライブラリの使用を義務付けている場合には特に、技術選択も制限されます。

p.75 「セマンティックバージョニングの利用」

> バージョン番号はMAJOR.MINOR.PATCHという形式です。MAJOR番号の増加は、後方互換性のない変更が行われたことを意味します。MINORが増えると、後方互換性のある新機能が追加されています。最後に、PATCHの変更は既存機能にバグ修正が行われたことを示します。

p.76 「異なるエンドポイントの共存」

> 破壊的変更をリリースしたい場合には、エンドポイントの新旧両方のバージョンを公開するサービスの新バージョンをデプロイします。これにより、新しいインタフェースを備えた新しいマイクロサービスをできる限り早く提供できる一方で、コンシューマに移行するための時間を与えます。

p.85 「フロントエンド向けのバックエンド（BFF）」

> バックエンドが使うさまざまな機能のビジネスロジックは、サービス自体の中に留まるべきです。BFFには、特定のユーザエクスペリエンスの提供に特化した振る舞いだけを追加すべきです。

第5章 モノリスの分割

p.94 「すべては接合部次第」

> 境界づけられたコンテキストが優れた接合部となります。定義によれば、境界づけられたコンテキストは、組織内の凝集性があり疎結合な境界を表すからです。

p.100 「共有静的データ」

> 多くの状況ではこのデータを構成ファイルかコードに直接追加するようにしています。なぜなら、大抵の場合に簡単だからです。

p.102 「共有データ」

> APIを利用してCustomerコードを経理や倉庫といった他のパッケージに公開できます。これを進めていくと、最終的には別個の顧客サービスになります。

p.103 「共有テーブル」

> テーブルを2つに分割し、倉庫向けの在庫リストテーブルとカタログ詳細向けのカタログエントリーテーブルを作成することです。

第6章 デプロイ

p.125 「継続的インテグレーションのマイクロサービスへのマッピング」

> マイクロサービスごとに1つのCIビルドを持ち、本番環境にデプロイする前に迅速に変更して検証できるようにする手法です。ここでは、サービスごとに独自ソースコードリポジトリを持ち、各リポジトリが個々のCIビルドにマッピングされています。

p.133 「イミュータブルサーバ」

> 稼働中のサーバには変更を行わないようにします。代わりにあらゆる変更はマシンを新規作成するためにビルドパイプラインを通過しなければなりません。

p.136 「サービス構成」

> 1つの成果物を作成し、構成を別に管理する手法です。環境ごとに存在するプロパティファイルや、インストールプロセスに渡すさまざまなパラメータで、これを実現できます。

p.137 「ホストごとに複数のサービス」

> 監視が困難です。副作用が起こりやすくなります。ホスト障害の影響分析もさらに複雑になります。サービスのデプロイも多少複雑です。チームの自律性も妨げます。スケーリングを最もひつユオとしているサービスをスケーリングするのが、複雑となります。

p.140 「アプリケーションコンテナ」

> 必然的に技術選択が制限されてしまう点です。 > コンテナの多くはクラスタを管理して共有インメモリセッション状態をサポートする機能を売り込んでいますが、サービスのスケールアウトの際に生じる課題があるため、これはどのような場合でも絶対に避けたいものです。 > コンテナの多くは起動に時間がかかり、開発者フィードバックサイクルに影響を及ぼします。

p.141 「ホストごとに1つのサービス」

> ホストごとに1つのサービスのモデルでは、1台のホストに複数のサービスが存在することにょる副作用を回避し、監視や改善がはるかに簡単になります。 > 単一障害点を減らす可能性もあります。仮想化プラットフォームを使っている場合は必ずしも明確ではありませんが、あるホストが停止しても1つのサービスにしか影響を与えないはずです。 > イメージベースのデプロイやイミュータブルサーバパターンといった、代替のデプロイテクニックを使う可能性が開かれていることです。

第7章 テスト

p.158 「単体テスト」

> 1つの機能やメソッド呼び出しを検査するテストです。

p.159 「サービステスト」

> 多数のサービスからなるシステムでは、サービステストは個々のサービスの機能をテストします。 > ※ スタブ / モックサーバ 「mountebank」

p.160 「エンドツーエンドテスト」

> システム全体に対して実行するテストです。

p.176 「デプロイとリリースの分離」

> ブルーグリーンデプロイメントでは、同時にデプロイされているソフトウェアの2つのコピーがあり、一方のバージョンだけが実際のリクエストを受けます。 > 本番環境のトラフィックを送る前の状況でサービスをテストできる利点に加え、リリース中に旧バージョンを稼働し続けることで、ソフトウェアのリリースに伴うダウンタイムを大幅に削減します。トラフィックのリダイレクトを実装するのに使うメカニズムによっては、バージョン間の切り替えが顧客から完全に見えなくなり、ダウンタイムゼロのデプロイが可能になります。

p.177 「カナリアリリース」

目的

エンジニアチーム内のメンバーが手軽に技術共有できるように

投稿したものはSlackに通知

人に読んでもらう文章を書く練習に

将来は他の開発チーム、デザインチーム、採用・広報チーム巻き込んで技術ブログを予定

使い方

esa.ioの使い方

方針

Share

とりあえず不完全でも共有。プルリクと同じ

はじめから完璧を目指さない。ドキュメントは途中のものでもWIPで共有

現時点での技術力が「高い・低い」や、「新しい・古い」は関係ない

ググれば出てくる情報や、ラボでやってて当たり前のことでも、自分の言葉で分かりやすく伝えられることが大事

Develop

共有した後に何度も更新して情報を育てる。履歴は残る

チームでゆるく共有して徐々に育てていく

気軽にフィードバックしてブラッシュアップ

よかったらStarを付ける。改善できそうな箇所、よく分からない箇所はコメント

Archive

情報が育ったらきちんと整理

タグ / カテゴリ付けをして後から探しやすいように

チャットのように気軽に発信、Wikiのように整理・編集する

いい記事を書くためのポイント

単なるハウツーにならないように、どんな目的があってそれをやったのかの背景を記載する

いつの時点での情報なのかと、バージョン情報は必ず記載する

コンパイル不可能なソースや実行不可能なコマンドを載せない

必ず手元で確認したものを載せる。動作環境の情報も添える

リポジトリや動作が確認できるものがあればURLも記載する

参考にしたサイトや本のリンクを記載する

基本機能

画像の添付が超絶楽

Markdown 対応 / リアルタイムプレビュー機能

スライドショーで簡単プレゼン資料となる

Markdown で記事を書いておけば、資料作成時間が大幅に削減できる

WIP（Work in Progress）で、未だ書きかけということを明示

カスタムテンプレート機能

カテゴリ、タグ設定が簡単で、変更時も一括反映できる

記事毎にコメント、スターによるコミュニケーション

記事をチームで育てていくことがやりやすい

https://www.amazon.co.jp/dp/4873116309

ミッションステートメント

> プログラマがソフトウェア開発を効果的かつ効率的にするために、他人の理解・コミュニケーション・コラボレーションの能力を向上させること

第1章 天才プログラマの神話

p.8

> 完成していないものを見られたら、何か言われるんじゃないかと本当に不安だ。細かいところまで見られて、バカだと思われないだろうか。

p.12

> 1人で仕事をするほうがリスクが高いということだ。誰かと一緒に仕事をすると、アイデアを盗まれたりバカにされたりしないかと不安になるかもしれないが、間違ったことをして時間をムダにすることを不安に思うべきだ。

p.13

> ソフトウェア開発はチームスポーツである。

p.15

> あらゆる人間関係の衝突は、謙虚・尊敬・信頼の欠如によるものだ。

第2章 素晴らしいチーム文化を作る

p.37

> 優秀なエンジニアは、自分で運転できるバスに乗りたいからだ。合意ベースのマネジメントであれば、チーム全体が意思決定プロセスに参加できる。

p.39

> エンジニアはコミュニケーションをできるだけ排除して、コードを書かなければいけないと考えている。しかし、チームが合意していなかったり、情報が伝わっていなかったりすると、君が正しいコードを書いているという保証はない。

p.40

> コミュニケーションの原則は、同期コミュニケーション(ミーティング)の人数を減らし、非同期コミュニケーション(メールなど)の人数を増やすことである。できるだけ多くの人が、プロジェクトの文書からすべての情報を取得できることが重要だ。

p.45

> 新しいものを設計するのであれば、ミーティングに5人以上参加させてはいけない。意思決定者がいない限り、部屋に5人以上いたら決まるものも決まらない。

p.47

> 1. 絶対に必要な人だけを呼ぶ > 2. アジェンダを作ってミーティング開始前に配布する > 3. ミーティングのゴールを達成したら時間前でも終了する > 4. ミーティングを順調に進める > 5. ミーティングの開始時間を強制的に中断される時間の前に設定する

第3章 船にはキャプテンが必要

p.66

> マネージャーはどうやって仕事を完了させるかを考える。リーダーはそのための道を作る。

p.69

> マネージャーの役割として最も重要なのは、執事や召使いのようにチームに奉仕することだ。サーバントリーダーとして、謙虚・尊敬・信頼の雰囲気を作り出さなければいけない。

p.77

> リーダーの仕事はチームの合意形成や方向性の決定を支援することであり、目標の達成方法はプロダクトを作る人が決定すべきことだ。

p.80

> 問題解決ならリーダーになる前に何年もやってきたので、すぐに問題解決モードに突入してしまいそうだが、それはダメだ。エンジニアが相談を持ちかけるのは、君に問題解決をしてほしいからではない。彼が問題解決するのを手伝ってほしいからだ。

p.81

> リーダーは障害を取り除くための答えを知る必要はない。取り除ける人を知るだけでいい。多くの場合、適切な答えを知るよりも、適切な人を知るほうが価値がある。

第4章 有害な人に対処する

p.100

> チーム文化に長期的な影響を与えるのは、開始時のチームである。最初の文化が弱ければ、他の文化に侵略されてしまう。受け入れられる振る舞いの基準を作っておけば、それが何年も続いていく。

p.102

> * ミッションステートメントを決めて、目標とそれ以外の両方に集中する。 > * メールで議論するときのマナーを作る。アーカイヴを保存して新来者に読んでもらえれば、時間の節約になる。 * すべての履歴を文書化する。コードの履歴だけでなく、設計決定・バグ修正・失敗なども記録する。 > * 効果的にコラボレーションする。バージョン管理システムを使う。コードの変更は小さくてレビューしやすいものにする。縄張り意識を作らずに「バス係数」を増やす。 > * バグ修正・テスト・リリースなどについて、明確なポリシーや手続きを用意する。 > * 新来者の参入障壁をなくす。 > * 合意ベースの決定を信頼する。合意できないときの衝突解消のプロセスも定義しておく。

第5章 組織的操作の技法

p.136

> 攻撃的な仕事は、ユーザーに見えるものである。見た目の輝かしいものであったり、興奮してもらえるものであったり、プロダクトのセクシーさを伝えるものであったりする(UIの改善・スピード・相互運用性など)

> 防御的な仕事は、プロダクトを長期的に健全にするためのものである(リファクタリング・機能の書き換え・スキーマの変更・データマイグレーション・モニタリングの改善など)

> 防御的な仕事によって、プロダクトの保守性・安定性・信頼性は高まる。だが、政治的な信頼性を獲得することはできない。

第6章 ユーザも人間

p.149

> まずは頭のいいプログラマの小さな集団が必要だ。そのチームに謙虚・信頼・尊敬の文化を育てる。サーバントリーダーとしてチームをリードして、みんなで協力してうまく意思決定ができるようにする。水・日光・方向性・内的動機付けを必要に応じて与える。文化を脅かしたり進捗を妨げたりするような破壊的振る舞い(や環境)といったネガティブな影響からチームを守る。

> お金を稼ごうと思うなら(あるいは履歴書に記入しようと思うなら)、他人がそのソフトウェアを使って幸せにならなければいけない。

p.164

> ユーザにとって使いやすいソフトウェアは、プログラマにとって作るのが面倒なこともある。コードを書く側の都合ではなく、ユーザーに集中しよう。

p.166

https://www.amazon.co.jp/dp/B009AALXCU/

プロローグ 人と人が響き合うチームを目指して

No.279

> 一旦決まり事をつくると、それをきっちりと守り、秩序正しく活動をすることを目指すようになります。いわゆる「手段の目的化」がおこるわけです。

No.387

> 優れた成果を生み続けるためには、まずは、土台となるチームを元気にすることです。

No.435

> 自律性と協働性を兼ね備えた「自律分散型組織」では、理念やビジョンといった中心軸をしっかり共有した上で、問題解決を現場に委ねます。

No.594

> 参加→納得→決意→行動→承認のサイクルを回していく。

No.681

> 会話とは交流のための話し合いです。その目的は、情報や気持ちを交換しながら、知識や経験を共有し、関係性を深めることです。

No.697

> それに対して対話は、探求と発見のための話し合いです。Ａという意見とＢという意見に対して、その上をいく新しいＣという意見をみんなで探し出すのが対話です。

No.712

> 交渉のように、異なる意見をぶつけ合い、最良の意見を選び取る（またはつくり出す）のが議論です。合意形成や問題解決を目的とした話し合い

No.727

> アジェンダ（議題）こそが話し合いのキモです。それによってチームの振る舞いも出てくるアウトプットも全く違ってきます。

第1ステージ 関係性を高める「会話」に火をつける

No.1128

> 自律的なチームをつくるには、ありとあらゆる情報をオープンにして、メンバー全員で共有するようにすることが重要です。

No.1180

> 話し合いの「見える化」です。ホワイトボードなどに意見を描きながら話し合おうというのです。

No.1303

> 偉い人や力の強い人が率先して弱みを見せましょう。これこそが、心のハードルを下げる強力な技です

第2ステージ 意味を共有する「対話」を巻き起こす

No.1416

> ワイワイガヤガヤとやるのが会話で、侃々諤々とやるのが議論なら、みんなが虚空を見上げたり首を傾げながら考え、おもむろにポツリポツリと語っていくのが対話です。

No.1619

> チームとは共通の目標（ゴール）を持った集団です。ゴールが明確になればなるほど、チームの力は高まります。

No.1757

> 分かりやすく言えば、「何を大切にして活動するか」です。「これだけは譲れない」「ここはこだわりたい」という“〝拠り所”〟です。

第3ステージ 行動を変革する「議論」を繰り広げる

No.1998

> まずは、「一体、本当の問題はどこにあるのか？」と、本質的な問題を探し出しましょう。

No.2029

> １つは、戦略レベルの問題です。分かりやすく言えば、方針、資源配分、基本構造など、方向性にからむ問題です。

No.2029

> ２つ目に、業務レベルの問題があります。今度は進むべき道は明らかでも、そのやり方がまずい、というものです。具体的には、仕事のやり方、システム、組織設計、制度、マネジメントといった、仕事のプロセスにからむ問題です。

No.2029

> そして３つ目は、文化レベルの問題です。モチベーション低下、モラル低下、能力不足、コミュニケーション不足といった、人に関わる問題です。

No.2185

> 発散と収束を混ぜない、というのが議論の大原則です。

No.2202

> それぞれが自分の持ち場で頑張って解決がつくなら、話し合いなんか必要ありません。大きな問題になればなるほど、役割を超えて協力し合わないと、問題の構造が打ち破れません。大きな目標のために、相互に踏み込み合い、みんなが自分以外の持ち場に対して協力を惜しまない──。そんな全体最適の視点に転換しないと、大きな問題は解決できないのです。

No.2257

> 一番大切なのは、優先順位をつける基準をしっかり話し合って、共有させておくことです。

第4ステージ 学習を促進する「省察」を深め合う

No.2366

> その際に大切なのは、自分たちで決めたことを１００％完全にやり切る ことです。

No.2590

> 自律型のチームを目指すのであれば、第一義的には成果ではなく行動を主に評価すべきです。すなわち、ミッションやビジョンにつながり、バリューを体現する行動をどれくらいしているかが、最大の評価ポイントとなります。

No.2664

> 「なぜそうなのか」「本当にそうなのか」「他の考えはできないのか」の３つの質問を使って、本質を見つけ出すようにします。

エピローグ 自律型チームの新しいリーダー像

No.3023

> 多くの支援型リーダーは「現場」をとても大切にします。データや伝聞情報を信用せず、自ら足繁く現場に足を運び、五感をフル稼働させて「今、ここで何が起こっているのか」をつかもうとします。

No.3099

WEBエンジニア向け(主にJavaのサーバサイド)の開発課題を作る機会があったので、 サーバサイド+フロントエンド+インフラ(AWS)の3つにカテゴリで作ってみた。 各課題の詳細は別途記事に書く。

概要

すぐフィードバックもらえるよう3日程度でできるもの

サーバサイドはAPIと管理画面に特化

サーバサイドだけするのではなく、フロントエンドチームとスムーズに連携できるように現状案件で使ってるフロントエンドの技術を知っておく

一般的な構成のインフラが構築できるように必須なAWSのスキルを身につける

基本(サーバサイド)

■ Java8 + play framework(最新)を利用

【課題１】RESTfulなAPIの作成 ※全員まずはこれをやる

【課題２】OAuthを使ったログイン/ログアウト機能

画面作成。OAuthはfacebook/twitter/Github

【課題３】課題１のAPIにトークン認証機能追加

課題2のOAuthで取得したトークンを利用

【課題４】定期ジョブ実行

日毎で外部API(facebook/twitter/Github)からデータを取得し、DBに保存する。管理画面で集計結果を表示

商品の登録/検索/編集/削除

※Spring Boot版 も選択肢に含める

フロントエンド

■ 基本の課題のRESTfulなAPIの作成をやった人向け

【課題１】基本課題で作成したRESTfulなAPIを叩く画面の作成

Node.js(npm)/ES2015/Babel/(webpack | browserify)/React

package.json、webpack.config.babel.jsは用意する

インフラ

■ サーバサイド/フロントエンド課題ともにやった人向け

【課題１】AWS上にサーバサイド/フロントエンドのアプリをデプロイ

EC2を1台のみで

【課題２】AWS上に役割ごとにサーバを分ける + 冗長構成を構築

EC2/RDS/S3/CloudFront

【課題３】CIサーバから自動デプロイ

Jenkins or CircleCI/Capistrano or Fabric

【課題４】独自ドメインとSSL証明書の設定

Route53/ACM/CloudFront/ELB

全体像

各課題はそれぞれ関連づいており、全ての課題をやることで下記の構成の1サービスとなる。

WEB+DBのvol.93の「モダンJavaScriptオーバービュー」を読んだので実際に手を動かしながらまとめてみた。

概要

言語：ES6(ES2015)

ランタイム：Node.js

モジュール管理：npm(Node Package Manager)

トランスパイラ：Babel

モジュールのロードとビルド：webpack

フレームワーク：React + Redux

文法チェック：ESLint

テスト：mocha + power-assert

ES2015

let / const ブロックスコープ

function f() { let x; x = 'foo'; x = 'bar'; const y = 'baz'; y = 'piyo'; // エラー return [x, y] }

アロー関数

const fruits = ['apple', 'orange', 'kiwi'] const unFruits = fruits.map((x) => x.toUpperCase())

class構文

class Shape { constructor(width, height) { this.width = width this.height = height } }

export / import モジュール分割

// 関数のエクスポート export function hello() { return 'Hello, World'' } // クラスのエクスポート export class HelloWorld { hello() { return 'Hello, World!' } } import { hello, HelloWorld } from '.lib/hello' hello() (new HelloWorld).hello()

Node.js

もともとサーバサイドで動くJavascriptだったけど、今はトランスパイラを含む開発ツールを実行するためのランタイムとして使われている。

npm

Node.jsのモジュール管理システムおよび、パッケージエコシステムの名前。Rubyで言うところのRubyGemsに相当。 Node.jsをインストールするとすでに入ってる。

モジュールのインストール

$ npm install axios

モジュール管理はpackage.json

npmにはRubyのBundlerのように、特知恵のプロジェクトで利用するnpmモジュールを、その利用バージョン含めて管理する機構があり、その設定ファイルがpackage.json。

package.jsonは、プロジェクトのルートディレクトリでnpm initコマンドを実行することで生成される。

{ "name": "es2015", "dependencies": { "axios": "^0.11.1" }, "devDependencies": { "babel-cli": "^6.9.0", "babel-preset-es2015": "^6.9.0" } }

package.jsonがあるディレクトリで引数なしでnpm installコマンドを実行すると、package.jsonに列挙されたモジュールがインストールされる。

Babel

ES2015のトランスパイラのデファクトスタンダードはBabel。

インストール

$ npm install babel-cli --save-dev $ npm install babel-preset-es2015 --save-dev

同ディレクトリにBabelの設定ファイル.babelrcを作る。

{ "presets": ["es2015"] }

Babelで変換

package.jsonのscripts属性に下記を追加。

"scripts": { "watch": "./node_modules/.bin/babel -w src -d dist", "build": "./node_modules/.bin/babel src -d dist" }

npm run build でsrc以下のソースコードを、トランスパイルしてdistに出力。 npm run watch でsrc配下のファイルの更新を継続的に監視し、変更されたらビルド。

実行はnode dist/{ファイル名}.js

webpack

importやrequireで読み込んでいるモジュール郡を静的解析によりロードし、ブラウザで実行可能な1つのファイルにビルドするツール。 Browserifyやwebpackがあるが、webpackの方が後発で、機能も豊富

インストール

下記をnpmからインストール

webpack ・・・ webpack本体

webpack-dev-server ・・・ 動作確認用のHTTPサーバ

babel-register ・・・ webpackの設定をBabelで変換するために必要なライブラリ

babel-loader ・・・ webpackとBabelを連携させるライブラリ

file-loader ・・・ webpackでHTMLなどの普通のファイルを扱うためのライブラリ

インストール後にpackage.jsonのscripts属性を設定。

"scripts": { "start": "./node_modules/.bin/webpack-dev-server", "webpack-build": "./node_modules/.bin/webpack --display-error-details" }

sudo npm run webpack-build でwebpackのビルドが実行され、 sudo npm start でHTTPサーバが起動。

サンプル開発

npmからMarkdownモジュールをインストールし、それを使ってMarkdownをHTMLに変換するサンプルを作成。

src/index.html

# Hello, World! - This is It - WEB+DB PRESS

src/app.js

import { markdown } from 'markdown' const elem = document.getElementById('markdown') console.log(elem) elem.innerHTML = markdown.toHTML(elem.textContent)

webpackの設定

webpackによるビルドの設定ファイル作成。

webpack.config.babel.js

import webpack from 'webpack' export default { context: __dirname + '/src', entry: { javascript: './app.js', html: './index.html' }, output: { path: __dirname + '/dist', filename: 'bundle.js' }, resolve: { extensions: ['', '.js'] }, devtool: 'inline-source-map', plugins: [ // new webpack.optimize.UglifyJsPlugin() ], module: { loaders: [ { test: /\.js$/, exclude: /node_modules/, loader: 'babel', }, { test: /\.html$/, loader: 'file?name=[name].[ext]' } ] } }

webpackの実行

sudo npm run webpack-build を実行するとビルドが走り、 distディレクトリにbundle.jsが生成される。この時Javascriptのソースはbabel-loaderによって、BabelｄeES2015からES5に変換される。

npm startを実行してHTTPサーバが立ち上がり、 http://localhost:8080/webpack-dev-server/ で動作確認が可能。

React + Redux

あんま書いてなかった。 詳しいことはvol.86、vol.87、vol.92を参照とのこと。

色々調べてみるとReactベースで使えるCSSフレームワークがあって結構よさそう。

keyがNULLになっているものをなくす

インデックスが使われているSQL文は、使われていないSQL文より高速です。 検索条件には指定されているのに作成されていないインデックスは作成しましょう。

filesortをなくす

レコード数が多いテーブルであればあるほど、filesortによる遅延が顕著です。 検索条件とソート条件によるマルチカラムインデックスを作成するとfilesortを回避できます。

rowsを減らす

フェッチされる行数が少ないほど実行速度は速くなります。 作成しているインデックス内に含まれる種類が多い(カーディナリティが高い)と検索性能は高まります。 複数の検索条件が指定されている場合は、カーディナリティが高いカラムにインデックスを作成するか、 該当カラムを含めたマルチカラムインデックスを作成することでフェッチされる行数を少なくできます。

レンジスキャンとソートの混在をなくす

レンジスキャンとソートがどちらも含まれる場合、インデックスの構造上、２つのカラムを含めたインデックスは利用できません。

ソート条件に昇順と降順を混在させない

https://mackerel.io/ja/docs/entry/integrations/aws

今日時点(2016/06/03)では以下の3つのサービスに対応してる模様。

ELB

RDS

ElastiCache

AWS連携は簡単で、IAM作って、上記3つのポリシー割り当てて、 設定画面でIAMのアクセスキーを入力するだけ。簡単。

ただ、今日突然ELBとRDSのconnectivityのエラーがslackに通知されてきたので、 調べてみたけど特にプロセスは正常に動作してるし何でだろ？って思ってたところ、 MLに「TrialプランからFreeプランに移行しました」ってメールが来てた。

https://mackerel.io/ja/docs/entry/integrations/aws

本機能はTrialプランとStandardプランのみの提供となります。

ちゃんと書いとる・・・。 FreeでRDSやELBも監視したいって時はpluginでやる感じなのかな？

開発中にふとER図を見たくなることがあるので、 SchemaSpyを使って生成し、それをJenkins上で公開させてみる。 ※別にJenkinsじゃなくてもいい。

http://schemaspy.sourceforge.net/

以下をJenkinsサーバ上で行う。

# jenkinsインストールされてるとこに移動 cd /var/lib/jenkins/ # 適当にjar配置するディレクトリ作成 mkdir lib # schemaSpy落とす wget http://jaist.dl.sourceforge.net/project/schemaspy/schemaspy/SchemaSpy%205.0.0/schemaSpy_5.0.0.jar # mysqlのコネクタ落とす wget http://search.maven.org/remotecontent\?filepath\=mysql/mysql-connector-java/5.1.24/mysql-connector-java-5.1.24.jar -O mysql-connector-java-5.1.24.jar # http://172.17.1.64:8080/userContent/schemaSpy/relationships.html この図作るためのツール入れる yum install graphviz # jenkinsの公開ディレクトリにDB定義書配置するディレクトリ作成 cd /var/lib/jenkins/userContent mkdir schemaSpy # 生成！接続情報は適宜変更で。以下コマンドをcronなりjenkinsのジョブで作って回せばいい。 java -jar /var/lib/jenkins/lib/schemaSpy_5.0.0.jar -dp /var/lib/jenkins/lib/mysql-connector-java-5.1.24.jar -t \ mysql -o /var/lib/jenkins/userContent/schemaSpy -host localhost:3306 -u root -p team-lab -db fields -charset utf-8

これで完了！と思ってたらER図が表示されなかったので調査して下記で対応。

Jenkins 1.625.3 からContent-Security-Policyが設定されたみたいでCSSや画像が読み込まれなくなってた。JSの実行も。 解決方法は「Jenkinsの管理」→「スクリプトコンソール」から下記コマンドを実行。

System.setProperty("hudson.model.DirectoryBrowserSupport.CSP", "sandbox allow-scripts allow-same-origin; default-src 'self'; script-src * 'unsafe-inline'; img-src *; style-src * 'unsafe-inline'; font-src *");

http://soqdoq.com/demarco/

今後も定期的に読み返すべきエッセイ一覧をピックアップ。

1 ハイテクの幻影

2-1 チーズバーガ工場式管理術(ミスの許容について)

2-2 チーズバーガ工場式管理術(人材の代替について)

3 ウィーンは君を待っている…

8 プログラムは夜出来る

14 ホーンブロワー因子

16 ここにいるのが楽しい

17 自己修復システム

21 スパゲッティディナーの効果

目的

新卒エンジニアに擬似プロジェクト開発を通して、チーム開発を経験してもらう。 開発の細かなTipsは度外視。エンジニアとしてのマインドを浸透させる 。

擬似プロジェクトで身につけて欲しいスキルは下記。

自分達のチーム(で|は|が)、

いいサービスとは何かを考える習慣をつける

どんなスキルセットの人がいて、どんなことができるのか把握する

限られた期間でどこまでならできるのか、何をいつまでにならできるのか見積もる

案件をスムーズに進めるために必要なツールを準備する

開発環境、リポジトリ、slack、redmine、ML、CI環境等

いなくなっても他の誰でもサービスを運用できるように考える

シンプルな設計・アーキテクチャ・コード

wiki等を活用した情報整備

ローカルPCではなくサーバ上で動作させる

どんなテストをすればいいのか考え、実施する

どうやってリリースするのか考え、実施する

作ったものを魅力的にプレゼンする

前提

座学でプロジェクトの大まかな流れを説明しておくこと

ここは結構しっかり。各フェーズで具体的にどんなことをやるかより、 　何故そんなことをするのか、それをしないとどんな悪いことが起きるのかをメインで

各フェーズで具体的にどんなことをするかは、擬似プロジェクトの進捗に合わせて適宜行う

4~5人の3チームで行う。メンバーはランダムで割り振る

あまり関わってない人ともコミュニケーションを取ってもらう

各フェーズの終わりは必ずレビュー。その他は相談がない限りしない

具体的にこれこれしなさいとは可能な限り言わない

選択肢は提示するがどうするかの検討・決定はチームでしてもらう

企画フェーズ

クライアント役の人からざっくりした要望を渡される。

必須条件は下記

ECサイトを新規で作って欲しい

扱う商品を簡単に管理できる仕組みが欲しい

初期データ(商品)は1万件

期間は1ヶ月

それをもとに実現可能かどうかは一切気にせず、 どんな機能があればいいサービスになりそうか考える。

例)PCサイト、SPサイト、スマホアプリ、管理画面... 例)フリーワード検索、色検索、CSVアップロード、おすすめ商品...

※会社にあったら便利な物を作った方がいいかなとも思ったけど、 そうすると色んな機能つけちゃったりとか、開発フェーズに焦点がいっちゃいそうなので今回はいいかなーと。 それよりもSIのプロジェクト全体の流れを把握してもらいたい。 開発フェーズは後で嫌という程できるし。

要件定義フェーズ

企画フェーズで考えてもらった機能を実現するのは多分ムリだろうから、 どの機能なら実現可能なのかを、

期間

メンバーのスキルセット

を考慮に踏まえ考えてもらい、その各々の機能を誰が、いつまでにするのかを決めてもらう。

※3チームとも同じ要件のものを作ってもらおうかとも思ったけど、 さすがにそれはつまらないしメンバーの能力によってもできることが変わってくるので、 あくまで自分達のチームなら何ができるのかを考えてもらいたい。炎上しないように。

設計フェーズ

設計フェーズでは要件で決まったものを資料に落としたり、成果物がどんどん出てくるタイミングなので、 今後のフェーズで必要となりそうなツール等を準備してもらう。

例)開発環境、リポジトリ(Git/SVN)、slack、redmine、ML等から必要に応じて。 それぞれのツールの使う方針も決める。

その後開発を進める上や、今後保守運用する上で必要そうな設計情報を資料として作成してもらう。 エクセルなり、Docsなり、Wikiなりを使って以下のなどを。

システム構成図

画面一覧・遷移図、機能一覧

DB設計図

その他必要があれば適宜。

開発フェーズ

言語、フレームワーク、ミドルウェア・・・メンバーのスキルに合わせて考えてもらう。

インフラ・・・AWS(アカウント作って渡す)

※あまり開発フェーズにばかり焦点を当ててほしくない。 ※案件の目的は開発をすることではなく、よりよいアウトプットを出すということ

コードは基本チームのみんなでレビューする(レビューというかみんなで見るという意識)

チケット管理なり、朝会なりでタスクや問題を把握できるようにする

また、開発フェーズの後半で突然の仕様追加をクライアント役から伝える。 そのままやるのでは炎上突入必死レベルの仕様追加。

言われたまま実現しようとして死ぬのもよし

代替案の工数があまりかからない機能を提案して対応するのもよし

別の機能の削減、テストフェーズの簡略化で対応するのもよし

　ただし期限は変えないようにして各チームがどう対応するのか見る。

テストフェーズ

ローカルPCではなくサーバ上(AWS)でアプリケーションを動作させる。 開発フェーズ中盤あたりからサーバ設計をしておく。

テストで意識することは、

どんな視点でテストするのか

単体、結合、セキュリティ、負荷

どんなものでテストするのか

OS(Windows, Mac)、ブラウザ(Chrome、Firefox、Safari)、iOS/Android、JMeter

またテストフェーズ中はインターネットには公開しない

リリース

案件開始から1ヵ月後の指定の時刻に3チーム一斉リリース。

ドメインを割り当てる

インターネットに公開する

チームのメンバーと喜びを分かち合う

プレゼン

せっかくいいものを作っても、うまく伝える・表現することができなければもったいないので、 発表資料作ってチームでプレゼンしてもらう。

メンバーの紹介とそれぞれ何をやったか

サイトを実際に見せながら説明。アピールポイント

各フェーズで工夫したところ、苦労したところ

また1からやるとしたら改善できそうなところ

前回「ボルダリング年表」を書いたので今回もボルダリング関連で。 色々買ったけどよかったのもあるし、もう続いてないのもあるなー。 シューズとチョーク以外をとりあえずピックアップ。

ヴァセリン

チョークで荒れる手にはヴァセリンで決まり！ これがないとボルダリングどころか普段の生活でも支障が出るレベル。 安いし量があるし潤うのにベタベタしないし。

ザバス ソイプロテイン100 ココア味

2014年7月頃から購入して今でも飲んでる。 あまり大きな筋肉はつけたくなかったからホエイじゃなくてソイに。 他にも色々プロテインあったけど、美味しいし特段不満はないので試してない。

ドアジム DOOR GYM

2014年10月に購入。 最近はジムに週４〜５で通ってるので家で懸垂する機会減ったけど、 気が向いたらやってる。順手で広背筋使うイメージで。

レーザーポインター

2015年5月に購入。 ホームセンターだと高すぎるのしかなかったので購入。 あったらとても便利だけど最近あまり使う場面がない。 経験の浅い子と登る時くらい？

OMRON エレパレス 低周波治療器

2015年7月に購入。 肩周りがずっと張ってた頃に整体で低周波治療受けたり、 銭湯の電気風呂入ったりして「電気すげー！」って感動したことから購入。 指(中指、薬指)、前腕、肩甲骨、広背筋あたりにやってる。 お手軽に低周波治療できて効果も高いけど、パッドがすぐヘタるのが難点。。

グリコ パワープロダクション エキストラ アミノアシッド

2015年9月頃から購入して今や必須。 ボルダリングした日は2粒、特に疲れを感じる日は4粒飲んでる。 これ飲んで寝たら、朝起きた時のカラダの調子が全然違う！・・気がする。

テックスメックス フィンガーローラー

これも2015年9月に購入。 この頃は指の力に頼って無理やり登ってた時期なので指痛めやすくなってた。 ローラーした後は指が気持ちいいくらい曲がって即効性はあるけど持続性はあるのかな？ とりあえず気持ちいいから今でもやってるけど、 今は指に頼らず背中を意識して登ってるから指の負担は減ってきた。

グリセリンカリ液P

2015年10月に購入。 ボルダリングしてると指の皮が硬くなってくるんだけど、 硬いより柔らかい方が苦手なスローパーを持てる気がしてる。 1週間に1回くらいの頻度で使ってるけど今のところ実感はなし。

La・VIE(ラ・ヴィ)Wモンスターマンローラー

2015年12月にTarzanで腹筋ローラーの特集で紹介されてたので衝動買い。 買った当初はやってたけど普通の腹筋ローラーで十分なのでもう使ってない

La・VIE(ラ・ヴィ) 私のストレッチ

2015年12月に購入。 背中を意識して登り始めたので当然背中が筋肉痛になりがちに。。 整体の先生にストレッチポールをオススメされたけどでかいし高いしだったので、 安くて小さいこちらを購入。風呂あがりにゴロゴロするのが日課に。 自重でこんなにマッサージできるの新発見。

点温膏K

2015年12月に購入。 背中で登る意識をしてるけどムーンボードやってたらやっぱり指に負担はかかる。。 なので指にピッタリなサイズの湿布探してたところいいのあった。 寝る前に貼ったら起きた時の指の軽さがすごい！臭いけど。

2014年の3月頃からはじめたボルダリングだけど、 気がついたら1年半以上経ったので自分がどの程度成長してるか気になり年表にしてみた。

ほぼジムでのボルダリングばかりで外岩は御岳が3回、小川山が1回で、 リードクライミングはまだやってない。(江戸川橋T-WALL近所なのに・・)

2014/3/18　四谷三丁目のAPEXでデビュー

初日で4級落としたのがすごく嬉しかったのかすぐにハマる

年内に1級落とす目標を立てる

2014/4　ホームをスポドリに変えて3級ゲット

この頃から週１で通いだす。昔のスポドリはしょぼかったなあ・・

2014/6　マイシューズを買う(RedChiliのマタドールVCR)

1足目なのにダウントゥにしてもた

2014/8　あきる野市の秋川渓谷でディープウォーターソロ初体験

2014/9　2級ゲット！

2014/10　印西市でリードクライミングの世界大会を見る

会場に向かうバスでアダム・オンドラと鉢合わせる！(今だともっとテンション上がっただろうなあ)

モチベ上がって大会後に登ったら1級ゲット！目標達成。

この頃から週1から週2くらいに増えた気がする

2014/11　ベースキャンプのアウトドアスクールで初外岩in御岳

何とか4級まではクリアしたけど、最後に少し触らせてもらった忍者返しには手も足も出ず・・

この頃は3週間くらい肩痛めててあまり登ってなかった

あと秋葉原B-PUMPで知り合った人と仲良くなる(今でも続いてる)

2015/1　マタドールVCRのつま先に穴が空いたので、ScarpaのINSTINCT VSを購入

つま先が強いんだけどとにかく履いてて痛い。痛すぎる

2015/2　2月くらいの雪がまだ残ってる時期に御岳のデッドエンド挑戦するも寒さで死ぬ

帰りによった河辺温泉の梅の湯で癒される

2015/3　ベースキャンプにてNORTH FACE CUP 2015の決勝を観戦

2015/4　ついに初段ゲット！

この頃から週3になる。強い新卒が2人加入してやる気出てきた時期

ついでに地元が同じ年上の変な人と知り合いになる。(よく一緒に登ることに)

飲み屋にINSTINCT VS置き忘れてすぐやる気なくした時期

今度はSPORTIVAのSOLUTIONを購入。履きやすい

2015/5/4　忍者返しリベンジするもクラックのところで落ちる。もう少し

2015/5/17　忍者返し三度目の正直でゲット！

結局その後2回も登って周りをシラケさせる

この頃からもっと登る頻度を増やしたいと思ってジムの近所に引っ越す(笑)

2015/6　スポドリで年1回の全面リニューアル&コンペ開催

80人くらいいて17位。上級者カテゴリには入ったけど決勝には残れず

はじめての突き指(左手の小指)。その1週間後にもまた突き指(左手人差し指)

ほぼ1ヶ月治らなかったけどその間も細々と登る。

2015/7　7月からスポドリの月会員になって週4~5ペースで登り始める

スラブ系が得意だったけど傾斜にも本格的に挑戦しはじめる

2015/10　小川山1泊ボルダリング

エイハブ船長落とせず。。別の1級課題をゲットする

色んなジムに行った。アンダーグラウンド、秋葉原B-PUMP、HEADROCK

2015/11　レースアップシューズが欲しくなってSPORTIVAのGENIUS購入

今までのどのシューズよりも自分の足に馴染んだ

この頃から背中(広背筋)で登る重要性に気づく。普段の懸垂も広背筋に効くように。

あと体調管理(よく風邪引く)のため、自炊を何年かぶりに再開

2015/12　スポドリではムーンボードをコツコツやりはじめる。

ベースキャンプ東京がオープンしたので登る。2級を4,5個くらい落とす

2016/1　ムーンボードの6Aを9割くらい落としたので6A+に手を出し始める

引き続きベースキャンプ東京に赴く。1級を2つ落とす