GGG

プログラミング言語やソフトウェア開発について思ったことを書いてます

プロダクションレディマイクロサービスを読んでみた

書籍を読んだものの、読みっぱなしになっていたので気づいた点をメモしておこうと思う。

動機

  • 所属先ではSREプロジェクトが立ち上がりジョインしているが、具体的に何をするのかよくわかっておらず勉強し始めた次第。
  • コンテナを用いた開発・本番運用が組織内で本格化している。
  • モノリシックなアーキテクチャからマイクロサービスへの転換が起こり始めている。

感想

大規模サービス向けに書かれている内容が多いです。 そのため、求められる基準がかなり高い。

私はスタートアップ系のため、うーん。ただ学ぶことは非常に多い。 これが全てできるようになったら大企業が行なっている品質基準を満たすことができるということがわかった。

これから少しずつ対応していきたい。

書籍でも対応するのに数年かかると言っている。焦らずに地道に対応して行くしかないですね。

思ったことについて、それぞれの項目の中で書いた。

概要

マイクロサービス化をした(あるいは、これからする)ものの、本番環境で利用するには何をすべきかについて 8つの評価基準を設けて、それについて語っているものです。

また、これとは別に可用性という9つ目の指標があるが、これについては8つの基準を満たすことで高い可用性を保つことができると言われている。

  • 安定性 (Stability)
  • 信頼性 (Reliability)
  • スケーラビリティ (Scalability)
  • パフォーマンス (Performance)
  • 耐障害性 (Fault Tolerance)
  • 大惨事対応 (Catastrophe Preparedness)
  • 監視 (Monitoring)
  • ドキュメント (Documentation)

8評価基準に対するメモ

安定性

変更によるマイナスの影響を緩和するための施策が用意されていること

安定したデプロイ 

開発環境 -> ステージング -> カナリア --> 本番

デプロイによる影響を最小限に抑える。また問題が発生しても自動的にリカバリーする仕組みが有ると良い。 カナリア:本番環境の2-5%程度のトラフィックを処理させて変更内容を検証する環境をいうらしい。しばらく、この環境で運用し問題がなければ本番環境にデプロイする流れ。

デプロイに失敗した場合に自動的にロールバックする仕組みが有ると良い。

所感

カナリア環境はないので、へぇー!と思った。用意してみたい。 また、デプロイ成功したんだけど、その後の継続的なヘルスチェックで失敗したらロールバックさせる仕組みが有るといいなと思った。

信頼性

  • クライアントやステークホルダーからみて安心して使えるマイクロサービスであることに対する基準
    • テストがしっかりされている
    • 安心、確実なデプロイ

クライアントはマイクロサービスを使っている別のマイクロサービスという意味も有るかも。

所感

  •  テストはしてるけど、十分にできているかは疑問が湧いた。今までと違った観点でのテストが必要かもしれない。

スケーラビリティ

  • トラフィックの増加に簡単に対応できる
    • できないと , レイテンシ増加、インシデント、機能停止に繋がる。
  • 質的な成長、量的な成長の二つの判断基準を明確にする
    • 質:ページビューなど
    • 量:毎秒何リクエストまで処理可能かなど
  • データ格納、処理する方法もスケーラブル
  • 急激なトラフィック増大(バースト処理)に対応できる

アーキテクチャのレビューを行うことでどこに問題があるか分かるらしい。

所感

  • ウィークポイントな気がする。書きたいことがいっぱいありすぎる。

パフォーマンス

  • 非同期処理によりパフォーマンス・スケーラビリティ向上ができるのに同期処理にしている ... 改善必要
  • コストが高い通信などの処理を大量に行なっている .. SQLの大量発行とか?
  • CPU,メモリなどのリソース割り当てを富豪的に使っている ... お金の無駄遣い? (コストパフォーマンス?)

所感

  • ウィークポイントな気がする。アプリケーション内の処理で改善できることがたくさんありそう。

耐障害性 / 大惨事対応

  1. 障害発生のシナリオを明らかにする
  2. 戦略を練る
  3. 計画を立てる

計画を立てて終わりだと、あまり意味がない。避難訓練みたいに実際にやってみることが大事。

データセンターがダウンしたことを想定し、あるリージョン上のインスタンスを強制的にダウンさせてみるなど。

アーキテクチャレビューを重ねることで、色々問題点が分かるみたい。 基本的にはSPOF(Single Point of Failure)を排除して行くことが課題になりそうだ。

やってみること

回復性テスト

  • マイクロサービスエコシステム、インフラに強制的に障害を発生させてテストする
  • カオステスト
    • 本番環境で障害シナリオを実行する。(ランダム&スケジュールされている)
    • 全ての障害シナリオに対応できることを証明し続ける。
    • Netfilixがやってると言われているテストでしょうか?

負荷テスト

トラフィックの急激な変化にどれだけ耐えられるか明確化する。また耐えられなくなった場合の対応措置を明確化する

手に負えない場合のシナリオ

どうしようもない場合に、何をすべきか決めておく。

連絡先の共有とかでしょうか?

所感

  • カオステストやってみたい。

監視

ロギング

必要な情報に簡単にアクセス、検索できることが重要らしい。 最近だと ElasticSearch , Kibanaとか?

必要な情報の定義が難しい。自分の解釈では問題が発生した際に再現をしなくてもログだけで原因がわかり修正ができる。ということかな。 再現できる不具合ばかりではないため。

GUI

dashboardとかの話。 サービスが健全で有ることがすぐ分かること。エンジニアでなくても見て分かることが重要らしい。 見せ方重要ですね。

アラート

効果的でアクション可能な主要メトリックに基づくアラート

障害の検知はアラートで行う。ダッシュボードを見ないとわからない・・・というのはよくないらしい。

  • 正常 , 警告、危険の3種類のアラートが有ると良いみたい。

所感

だいたいできてるのかな。ただ改善点は有る。

ドキュメント

  • 一元管理
  • 簡単にアクセス、検索できることが大事。

所感

ドキュメントはいくつかの場所に散在しちゃってて、改善したいと思ってました。

その他

  • マイクロサービス間の通信について
    • RPC(リモートプロシージャコール)を介したやりとり ... 非同期
    • REST APIによるやりとり ... 同期

マイクロサービスエコシステムの4層モデル

layer / 対象 備考
4 マイクロサービス
3 アプリケーションプラットフォーム
2 通信 サービス間の通信。DNS, RPC, API サービス検出、サービスレジストリ、負荷分散
1 ハードウェア Machine, OS , Docker,...

アンチパターン

  • APIをバージョニングすること

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

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

オリジナルはこちら

Production-Ready Microservices: Building Standardized Systems Across an Engineering Organization

Production-Ready Microservices: Building Standardized Systems Across an Engineering Organization

アジャイルな見積もりと計画づくり

職場の同僚からのお勧め本。

今回はいつもと違う感じでストーリー調に書いていきます。

状況把握

初めに、私はある新企画プロジェクトに参加することになったエンジニアです。リーダーの立場です。 開発メンバーは新卒です。他に企画系が2名います。

新企画プロジェクトの現状はだいたい作りたいものが決まっている状態です。 メンバー、リリース時期もだいたい決まっています。 ただし、仕様が決まっていない状態です。

ガントチャート / 試しにスケジュール作ってみる

そこで試しに「やること」を洗い出しました。 何も決まっていないのに、ステークホルダーから、いつ頃までにリリースできるか?といきなり聞かれたためです。 困りました。仕様も決まっていないのにリリース日が先なんです。

とりあえす「やるだろう」な項目を洗い出して、ガントチャートに起こしました。 また、困りました。

今回は、新卒のメンバーがいるため工数がとても出しにくいです。 作業スピードがどのくらいなのか、わかりません。まだ仕事にも慣れていない状態です。

出会い

これ読んで見たら?・・・紹介されました。

アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~

アジャイルなプロジェクト計画と見積もり

プロダクトバックログと見積もり(story points)とvelocity

これを元にこれから始まるプロジェクトのバックログを作成&見積もりをやって見ました。 プロダクトバックログは、プロダクトに必要な項目がまとまっている表のことです。

(この本では見積もりは、複数人でやることを推薦しておりますが、今回は一人でやりました。バックログの各項目はユーザーストーリという形でまとめたりするそうです。今回は機能(フィーチャー)という形式でまとめました。この時点であまり詳細化しない方が良いそうです。大きい単位はエピック、テーマなどと呼ぶそうです。)

バックログは着手すべき優先度の高い順序に並べます。(現状は、仕様が未定なのでとりあえず推測です)

見積もりは、基準の機能(だいたい何するか分かる機能)をピックアップして、ストーリーポイント=5としました。 あとは、相対と直感でどんどん見積もっていきます。見積もりは作業時間ではなく「規模」で見積もっていきます。 作業時間だと熟練度で差が出てしまうためです。

ストーリーポイントは1,2,3,5,8,13,21,... とフィボナッチ数で見積もっていきます。 5が基準です。

イテレーションを1週間と仮定した場合にストーリポイント=8が一人でクリアできそうなイメージです。

(書籍では、一人でこなせるストーリポイントは算出不可能な方が良いと語っております。ただし、今回はエンジニアが2名で1機能が一人ずつ一任して達成していくイメージで考えていたため、8 x 人数 --> velocity と考えられそうです。ベストプラクティスではなさそうですが・・。)

ところでvelocityは、実際に数イテレーションこなしてから平均化のようにしていくと良いようです。 将来的にどれくらいストーリポイントをこなせるか分かるためです。まだ一度もイテレーションを実施できていないので現状は推測です。

不確実性コーン

ところで、見積もりは不確実であるということを前提に行います。 不確実性コーンというものがあります。

要はプロジェクトの初期ほど不正確で後半になる程正確になることを表しています。 現状はプロジェクトの初期のため(まだ始まってもいない!)かなり不正確です。

http://itpro.nikkeibp.co.jp/article/COLUMN/20131001/508039/zu01_s.jpg

リリース計画

これで下記が分かりました

  • プロダクトバックログ
    • 合計のストーリポイント数.... (sp)
  • velocity .. 推測 ... (velocity)
  • リリース日
  • イテレーションの期間 ... (iteration)
    • 仮で1週間

この情報から下記の計算式により、リリース時期が見えてきます。

sp / velocity * iteration -- > 必要なイテレーション

この情報に、 * 年末年始、GW、メンバーの長期休暇、祝日の日数 * 不正確な見積もりのため、不確実性コーンを参考に最短、最長の予測をいれます。

これらを加味すればいつ頃にリリースできそうか見通しが立ちそうです。

もうガントチャートは不要です。

リリース計画ができました。

机上の空論にしてはなかなか良さそうです。

着手する「やること」、その順序も分かりました。ちょっと安心しました。 あとは、実際のvelocityが不明なのでイテレーションをやってみないと分かりません。 予定よりもできない可能性は十分あります。

今回は仮想のプロダクトバックログを相手にリリース計画を作りました。 予行演習ですね。

近々、プロダクトバックログをみんなでまとめる打ち合わせがあるので、そこでプロダクトバックログができそうです。

所感

リリース計画は、イテレーションが始まった後も絶えず更新し続けます。 初めに作って終わりではないそうです。

イテレーションのレビュー内容を元に新たなバックログが追加されるかもしれません。 このようにして積極的に変化を受け入れていくのだと思います。

イテレーションでは最優先の項目が順に消化させていきます。 MUSTの項目さえ終わっていればリリースできる状態にはなりそうです。

そのためには、ある程度カテゴリ付けして置いた方がよかったかもしれません。 書籍には下記の4つが紹介されてました

  • must have ... 必須
  • should have ... 重要
  • could have ... 有効
  • won't have ... 不要

イテレーション

まだ始まっていないので....

また後でモチベーションがあったら書くかも

キーワード

  • 不確実性コーン
  • ストーリーポイント(story points) / 理想日 / 理想時間
  • リリース計画
  • イテレーション

  • タイムボックス

  • ユーザーストーリー
  • フィーチャー
  • エピック、テーマ
  • プロダクトナレッジ、プロジェクトナレッジ
  • ベロシティ(velocity)
  • バッファ
    • フィーチャバッファ
    • スケジュールバッファ
  • バーンダウンチャート
  • ストーリーポイントの見積もりは10倍以内
  • ゆとりを持った計画 ... 75%くらいにしておくと良い。
    • 会議とか、割り込みとかを考慮

アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~

アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~

【感想】スモール・リーダーシップ

最近きになる書籍があって、読みました。

「スモール・リーダーシップ」という本です。

あとで内容を再確認できるように軽くまとめておく。

書籍のターゲット

著者はIT業界の人と思いますが、業界は特に関係なく全ての業界の小チームのリーダーの人、なったばかりの人がターゲットです。 またそこに属するメンバーにも読んでもらいたい良書だと思います。

と思われる。

小チームとは8人くらいまでのようだ。

結論から先に

平易な文章で書かれているため、読みやすかった。 良書だと思います。

ぜひ、みんなに進めたい。

気になったキーワードをまとめてみる。

  • リーダーの振る舞い
    • サーバント型リーダー
    • 調停役
    • メンバーが自律的に行動。
  • リーダーの役割
    • チームとして成果を最大化 ... プロジェクト、スケジュール管理など
    • チームメンバーの成長を最大化する
  • 凡事徹底。規律の醸成。メンバへの敬意
  • 会議でホワイトボードは積極的に使う。 - > フレームワークの利用
  • 様々な場面で効果フレームワークを適用し、抜けなく漏れなくする。
  • 図解力
  • 議事録は残そう

フレームワーク

論理的思考

  • 網羅性、整合性

抽象 -- > 具体化

例示(for example) 対置(exclusion) 包含(inclusion) 等価(equation)

問題解決

その1

  • 現状 / 前提(制約条件など)
  • 目的・目標
  • 課題
  • 解決策

課題と解決策は分けて議論した方が良さそう。

その2

  • 仮説
  • 検証

図解

  • 静的構造
    • 家の間取り図のようなもの
    • ER図, クラス図、etc
  • 動的構造(時間軸に沿った変化)
    • 新聞の番組欄のようなもの
    • シーケンス図

自身に置き換えて考えてみる。

現状

  • 小チームのリーダーとなり1年近く経過しました。
  • 新規にプロジェクトが立ち上がろうとしており、今のチームを離れて新しいチームのリーダーとして活動が始まっております。

そこで、この一年間を振り返る、見直そうと思っていた矢先にこの本に出会いました。

私は、IT業界でエンジニアとして従事しており、開発チームのリーダーの立場です。 これまで従事していたプロジェクトのエンジニアチームは、私を含めて2-4名。企画も入れると最大8名程度のプロジェクトチームです。

どちらかと言うと支配型の要素が強いリーダーだったかも知れません。 上司からももう少しチームメンバーに自律性を育むような体制になればとても良さそうだと言われたことがあります。

目的・目標

サーバント型のリーダーになるにはどうしたら良いか?

課題

ある日から突然、完全サーバント型に切り替わって(人が変わったような)しまうときっと混乱を招くだろうと思います。 指示を出さない上司、指示待ちの部下と言う構図は悪循環になります。

解決策

焦らずにチームメンバーの自律性を時間をかけて育んで行くことを目標とする。

そのためには、仕事一つひとつに問題意識を持って自然と行動できるチームに少しずつ変えて行ければ自然と自律性は醸成されるのではないかと思う。 問題意識を持つためには、仕事の目的・意義などについて1件1件丁寧に考察を繰り返していくことが良いかも知れない。 また、チーム内で改善提案をより発言・受け入れられやすい態勢にして行くことが必要だろう。

そうすれば徐々に変わって行くと思う。 至極当たり前のことだけど、これを徹底することが必要なんだろう。

スモール・リーダーシップ チームを育てながらゴールに導く「協調型」リーダー

スモール・リーダーシップ チームを育てながらゴールに導く「協調型」リーダー

Mac導入時にやること #2 バックスラッシュをより簡単に

環境

  • mac book pro 2017
  • USキーボード
  • OS : Sierra(10.12.6)

option + \ でバックスラッシュをタイプするのがめんどくさいです。 キートップに ‘\'が印字されていますが、押すと¥ が出力されます。

うーん。

調べたらありました。 会社で使ってるmacでそんな設定したかな?覚えてない・・・。

スクリーンショットがあったほうがわかりやすいと思うので掲載しておきます。

手順

1. 右上にあるAをクリックして「"日本語"環境設定を開く」を選択

f:id:taisyo7333:20170903154935p:plain

2. 「入力ソース」を選択し、”¥”キーで入力する文字をバックスラッシュ”\”に変更する

f:id:taisyo7333:20170903154949p:plain

以上、めでたし。

参考サイトによると、ほかのIMEをご利用の場合は別の設定が必要のようです。

qiita.com

Mac導入時にやること #1 Sierra ,emacs , metaキー

最近、macbook pro 2017を買いました。

仕事でも使っているのですが、 emacsでのメタキーの位置が悪くて以前に「Optionキー –> Metaキー」に設定したのですが 設定したのが数年前でどうやってるのか思い出せませんでした・・。

見つけたサイトと設定場所は変わってませんでしたが、少し古かったのでスクリーンショットを掲載しておきます。

設定手順

「Terminal」 –> 「環境設定」 –> 「プロファイル」 にある「メタキーとしてOptionキーを使用」にチェックを入れると解決する

f:id:taisyo7333:20170902225616p:plain

playet.jugem.jp

「React Design Patterns and Best Practices」を読んだ

発売日に予約したのに、積読状態だった書籍を消化。

書籍名がステキで思わず購入。先日ようやく読み終わった。

個人的には、とても良書だと思う。 reactを使って開発しているエンジニアにはぜひご一読いただきたい書籍だと思う。

タイトルから想像がつくように初学者向けの書籍ではない。 規模はともかく「すでにreactの開発したことがある」ことを前提にしていると思う。

ただしタイトルの「ベストプラクティス」という表現は適切か分からない。ここ注意

まだ模索中の方法論もあり、この問題を解決をするには今はこんな方法(npm library)があるよ!!っていう紹介が多い。 ただし、使い方の紹介だけでなく技術的な背景が説明されているため机上だけでも十分理解できる内容となっていると思う。

目から鱗が落ちるアイディアも確かにあったり、問題と認識してなかった部分について問題意識を持つことができた。

忘れないうちにまとめてみたい。

HoC ( Higher-order Component)

T.B.D.

Server side rendering –> client side renderingのデータ受け渡し

T.B.D.

Data Fetch を宣言的に書く

T.B.D.

Regular CSSはスケールしない

T.B.D.

React Design Patterns and Best Practices

React Design Patterns and Best Practices

docker build で 「no space left on device」と出たらやること

docker利用時にタイトルのno space left on deviceが出た場合に下記の2つを実施して解決。

やる前に

  • 稼働してるコンテナを止めた方がいいよ。

その1

コンテナの削除

docker ps -aq | xargs docker rm

イメージの削除

docker images -aq | xargs docker rmi

その2 (別のやり方)

2017/09/30追記

docker system prune -a

docs.docker.com