2019-09-02

データ指向アプリケーションデザイン読書メモ：1章

今日16時から社内勉強会やるよー！

普通に書いてる分は運用で、（chaspy）がお気もち

データ指向アプリケーションデザイン ―信頼性、拡張性、保守性の高い分散システム設計の原理

作者: Martin Kleppmann,斉藤太郎,玉川竜司
出版社/メーカー: オライリージャパン
発売日: 2019/07/18
メディア: 単行本（ソフトカバー）
この商品を含むブログを見る

信頼性、スケーラビリティ、メンテナンス性に優れたアプリケーション

多くのアプリケーションは演算指向ではなくデータ指向
- CPUの演算能力より、データをどう扱うか、がボトルネックになりやすいことを示す
  - データ量
  - データが変化する速度
本章ではデータシステムで以下の課題をどのように解決するかを考える
1. 信頼性
2. スケーラビリティ
3. メンテナンス性

信頼性

何か問題が生じたとしても正しく動作し続けること
問題を起こしうるものをfaultと呼ぶ
faultによって、システム全体がユーザにサービスを提供できていないことを障害（failure?）と呼ぶ
- ref: http://www.sei.cmu.edu/reports/92tr033.pdf
障害には大きく以下の3つに分けられる
1. ハードウェア障害
2. ハードウェア障害は常に起きる
3. 通常RAIDなど冗長化していて、fault traranceを持つ
4. 仮想マシンというレイヤーで考えても、AWS EC2インスタンスが使用できなくなることもある（chaspy）
  - メンテナンスのため再起動が走ったりもする（chaspy）
  - クラウドを使う上でも、落ちてもいいように設計すべき（chaspy）
5. ソフトウェア障害
6. システム内でのシステマチックなエラー
  - ソフトウェアのバグ、特定の入力があるとクラッシュする、など
  - プロセスの暴走によってリソースを使い切る
  - 依存するサービスの問題
  - カスケード障害
7. 解決策は？->ちょっとした積み重ね
  - 徹底したテスト
  - プロセスの分離
  - プロセスのクラッシュと再起動の許容
  - 計測
  - モニタリング
  - プロダクション環境におけるシステムの挙動分析
8. このあたりはReadiness Check / 負荷テストでサービスインのときに把握できるようにしたい（chaspy）
9. ヒューマンエラー
10. 人間には信頼性がない
11. 人間はスケールしない（chaspy）
12. ではどうするか？複数のアプローチを組み合わせる
  - インターフェースによって正しいことを行いやすく、間違ったことを行いづらくする
  - サンドボックス環境をプロダクションと分離して提供して経験を積む
  - すべてのレベルで徹底的テストを行う
  - 設定のロールバックを即座にできるようにする
    - これは1番大事だとQuipper SREに入って学んだ
  - 詳細で明確なモニタリングの仕組みをセットアップする
  - 優れた管理方法とトレーニングを実践する
    - オンボーディング、教育、ドキュメンテーションあたりが関連か
信頼性の重要度
- これ最近考えているテーマだった。何かしらで重要度をつけてRediness Checkを軽くしたりできないかなあと（chaspy）
  - SLOを低く、あるいは設定しない、というふうにするのも一案かなあと思うが悩む（chaspy）
- アプリケーションが「クリティカルではない」ものであったとしてもユーザに対する責任は発生します
- 信頼性を犠牲にすることで、開発コストを下げたり、運用コストを下げたりする場合もあるが、その場合信頼性を犠牲にしていることを強く意識しておくべき

スケーラビリティ

負荷の増大に対してシステムが対応できる能力
どのようにコンピュートリソースを追加すれば負荷に対応できるか？
Twitterの事例
- ホームタイムラインの取得の際の負荷の問題
  - 読み取り時の処理を少なくし、書き込み時の処理を多くした（書き込み頻度のほうが2桁小さいので）
- また、極めて大量のフォロワーを持つユーザは最初のアプローチをとり、ハイブリッド型とした
パフォーマンスの表現
- スループット
- レスポンスタイム
  - 通常外れ値があるので、mean(50 percentile)、95 percentile, 99 percentileを使う
  - 99 percentileはテイルレイテンシ、ユーザ体験に影響していることが多い
    - Amazonの例では99.9 percentileを指標にしている
    - 1/1000しか影響しないが、そのユーザは大量に購入しており重要な顧客である可能性が高い
    - この考えは自分にはなかった、遅いから気にしなくていいと思ってた（chaspy）
    - レスポンスタイムと売上の相関が見れると良いな、うちでいうとどうだろう？学習継続率とか？（chaspy）
負荷への対処のアプローチ
- 負荷が10倍になったとき、アーキテクチャを再考する必要があるだろう
- スケールアップとスケールアウトがある
  - 実際、直近はMongoDBをスケールアップした（chaspy）
  - MongoDB自体はスケールアウトの仕組みを持っているが、複雑度が増すため見送っている（chaspy）

メンテナンス性

3つの設計原理
- 運用性
  - 運用者が扱いやすいものにする
  - 個人の出入りがあっても、システムに関する組織の知識が保たれるようにする
    - 大事だと思う（chaspy）
  - デフォルトの挙動を優れたものにする
  - 総じてドキュメンテーション、自動化、コード化がこれらを支えると思う（chaspy）
- 単純性
  - 偶発的な複雑さを取り除くこと
  - 優れた抽象化をする
- 進化性
  - アジリティのこと
  - 運用性、進化性に大きく依存する

まとめ

ソフトウェア・システムには機能的な要求、非機能的な要求があり、後者のうち信頼性、スケーラビリティ、メンテナンス性を取り上げた
これらを簡単に高める方法はないが、くり返し現れるパターンやテクニックは存在する
今後の章でデータシステムがこれらの目標にどのように向かっていくのか考察する

感想

SREとして働く上でもっとも重要な3つの概念を改めて言語化、整理されていて非常に良かった
SLOを定める上でパフォーマンスの表現の章が密接に関わる。レイテンシは複数のパーセンタイルで分析したいと思う。
スケーラビリティ、メンテナンス性はReadiness Checkでのアーキテクチャレビューで担保できるようにしたい。現状アーキテクチャレビュー、事後の説明になってしまっていてあまり効果的に働いていないので
メンテナンス性に関しては経験を持った個人に依存している部分も多くあると思っており、課題を感じている。ドキュメンテーション、コード化のいいバランスを考えたい。（すべてをドキュメント化すべきだとはもちろん思っていない）

勉強会終わったあと追記します。

2019-08-29

datadog-aws-ec2-counter はべんり / OSSへContributionすること

はじめに

べんり

github.com

最近クラウドのお金まわりと"ちゃんと"しようとしていまして。Quipper では以前よりこの datadog-aws-ec2-counter を利用してインスタンスの使用状況を可視化しています。

これは Instance の hootprint の数値が Reserved Instance と Ondemand instance でそれぞれとれるスグレモノで、利用的には Ondemand instance で長期間動いているものは Reserved Instanceを買うべきですし、Reserved Instanceを買っているが使っていないものがあればそれはもったいないということになります。

AWS、Reserved Instance を買う行為自体めちゃくちゃしんどいですし、（UI的な意味でも、高額で間違えられないという意味でも）Reserved Instance を買う前の計画を立てるためにもとても有効なツールです。

Pull Requestを送った

ある日、突然これまでとれていた metrics が取れなくなってしまっていて、原因を調査したところ簡単な修正で治ったので Pull Request を送りました。

github.com

メンテしていた @mounemoi さんがまだ在籍されてるか不安だったので、mixi SREの清水さん @isaoshimizu に連絡したところ、見ていただいてマージしてもらえました。いい話だ。

OSS にシュッとPRを送ること

一応職業プログラマ、ソフトウェアエンジニアとしてn年働いてるわけですが、「OSS に Contributeする」というのは自分にとってとてもハードルが高い行為で、「やりたいんだけどできない。できるようになりたい」とかなり長い間思っていたような気がします。これをふつうに、というか、できるものとできないものはあるでしょうが、やろうと思うハードルが低くなったのは、そして実際にやれるようになったのは直近の1、2年です。

新卒当初は Rails の内製のソフトウェアを開発していました。Rails はもちろん OSS だし、使う gem ももちろんそうで、やれてもいいものですが組織内にまったくそのような文化がなく、その発想すらなかったように思います。

そしてその次が OpenStack で、このときは組織として Contribution していくぞ、という雰囲気があったんですが、お作法がわかってなかったり、取り組むステップがわからなかったり、何しろ大規模であるということ、Python に習熟していなかった（これは言い訳っぽいな）こともあり、このあたりで意識は芽生えるものの全然行っていませんでした。社内にはトップ Contributer も在籍していたので、今思えば教えを請えばよかった話なんですよね。そのひとがメンターで見たインターン生が OpenStack にパッチを出していて情けない気持ちになったのを思い出したりしました。

もちろんいまでも大規模な、例えば OpenStack や Kubernetes の内部へ Contribution するのは"すぐには"できないでしょう。しかし、Terraform AWS Provider へいくつか Contribution した経験を通しても時間をかければできるところはあるだろうし、それ以外のDocumentや、非常に簡易な修正でも、いくらでも貢献方法はあるわけです。

合わせて重要なことはなるべく最新版を使う、そのためには定期的な Upgrade を "ちゃんと" やるというのも、難しいですが非常に重要な点だと思います。

OSS を使って困ったことに遭遇したら

まず upstream を見る、cloneして、grepして、コードを読む
直せそうか考えてみる
難しそうであればissue、または一部分だけでもPRとして出す
詳しいひとに相談する

こういう小さい、でも当たり前のことの繰り返しでそれはできるし、こういうハードルを下げればいいだけなんだなぁと、実感するばかりです。でも昔から今もこういうことは多く発信されてると思うので、なんで自然とできるようになったかというと、OSSで見つけた不具合を大小、ロジック・ドキュメント問わずさっとPRを出す、そういうことを当たり前にできる仲間が多い環境にいるからで、やっぱり環境は大事だと再実感するのでありました。

人生にはこういう「その状態に達してみないと気づけない、しかし重要なこと」が多くあり、だからこそチャレンジが大事だな、とも。

おわりに

Growth - Hack the growth curve for you and your team We all have a passion for learning. Stay curious and thirsty for new things, and don't be afraid to take a leap. Always keep yourself out of the comfort zone.

Always keep yourself out of the comfort zone

Growth は Quipper の 5 value の1つです。

2019-08-28

英語週報8/18~週

英語週報つけることにした。1年頑張ろうな。すでに遅れてるんだけどね。

どうしたの急に

8/18に一念発起した。

約1年前に英語を"前職よりは使う（ただしメインはテキストの読み書き）"という環境に転職したが、特に英語力は伸びていない。なぜかというと勉強してないから。英語力ってなんだって話はいったんおいといて。

「やらなきゃなー」で甘えてたんだけど、ソフトウェアスキルへの投資を少しでも緩めるのが怖い、ということを言い訳に着手していなかった、ことに気づいた。それはやはり優れたソフトウェアエンジニアである同僚が毎朝習慣的に英語学習をしていることを知ったからだ。「習慣にしてますね。」自分の甘さに気づくのはこの一言で十分だった。

そんなこんなで論理をすっ飛ばしてとにかくやれ、ということでいろいろ手を出しつつも、最低限オンライン英会話は毎日やる、ということを決めた。もちろんこれだけでは足りないので随時足していくしいろいろ試していく。

英語が優れている仲間たちに英語を勉強していること、勉強の方法について相談したら、基礎が遠回りに見えて近道なので、まずは英検2級を問いてみてはどうか、それがスラスラ解けるならより高いものを、そうでないなら基礎を固めたほうがいい、という趣旨だった。

高校卒業程度の3000単語の語彙あるいは基礎文法がないまま英会話するよりは先にそれを固めたほうがいいというのももっともだし、何かしら今の実力を継続的に測定したり今の自分の位置を知る手段がほしいと思っていた。（英検はpass or fail の2択なのでなんともだが）10月に受けることにした。あっさり受かるならそれはまぁそれでいい。

LTで退路を断ったり、前述の尊敬できる同僚に1on1でのコーチング、メンタリングをお願いしたり、チャットでワイワイしたりして退路を断って、ひとまず10日間続いている。すごい。

とりあえず1年やりきれば絶対に何かしら効果は出ると信じてやる。もちろん、盲目的に1つのやりかたをやる、だったり、ただ無為に英会話25分を過ごすだけにするつもりもなく、そのための週報だったり1on1での振り返りはしっかりしていく。

ちなみに意外とできた！って話かというとそうではなく、"ちゃんとしんどい"です。英語は楽しくやるのがいいとか、それはそうなんだけど、ちゃんと仕事はしないといけないわけで、幸運なことに（？）決して仕事がヒマではないので、変わらない仕事の負荷は継続しつつ英語の勉強をしないといけなく、覚悟はしていたものの"ちゃんとしんどい"です。とはいえもうやりはじめたのでやりきりますが。

ゴールはなんだっけ

海外カンファレンスでディスカッション、あるいは質疑応答ができること
Software Enginnerとしてできないと成長を阻害する（後ろ向き）
仕事をする上でできないと成長を阻害する（後ろ向き）

というわけで、やっぱりSREConに行ったことはたしかに次につながったわけで（ちょっとラグあったけど）コンフォートゾーンから出ることの重要さを実感するばかりです。

blog.chaspy.me

強く思ったことは、強くなってまたここに（厳密に同じSRECon Asiaという意味ではなく、海外カンファレンスという意味で）帰ってきたいということだ。

振り返り

このへん。

で、まさに英会話やディクテーションはその量を増やす、あるいはその結びつきがない言葉を知る行為だから効果的なんだろう、英語週報ブログに書こうっと。
— 🤔 (@chaspy_) August 24, 2019

なんかいろいろ手法とかあるけど、シンプルにこの量を増やすことが本質的で、加えてスピーキングでは言いたいことを結びつける作業をすればいいと思う。だから、ただたんにDMM英会話をするだけじゃ効果は半減なのは言うまでもない。「これ言いたいから調べさせて」と言ったら快く待ってくれるのがありがたい。教材を使っても1回に数個は知らない単語は出てくるので、その音と一緒に覚えることができる。これはやってみいないとわからないことだった。やっぱり人生はやってみないとわからないことが多い。

ちょっと細かい英語の振り返りもするつもりだったけど遅れているので決意表明まで！来週からちゃんと書くぞ。

2019-08-19

Alibaba CloudにISUCONの模擬試験環境を構築する（Terraform編）

はじめに

した。

github.com

さて、今年もISUCON出ます。去年何もできなかった自分に対して圧倒的な成長を実感できる予感がしています。

チーム内でいろいろ作戦会議をしてますが、最初の30分それぞれ何をするのか、そして実際にできるのかの模擬練習をしておいたほうがいい、という意見が出まして、ヨッシャ環境構築するぞとなりました。

Alibabaもalicloud providerもはじめてでしたが、なんやかんやでとりあえず1台インスタンスが立ってGlobal IPにsshできるところまできました。

事前準備としては - Terraform userの作成、Administrator権限の付与 - keypairの事前登録、keypair名をtfファイルに更新

ができれば動くはずです。ちなみにちゃんとTerrafrm 0.12.6にしました。ちゃんとした。

Alibaba Cloud、普段クラウド触ってればだいたい雰囲気同じ感じでなんとなしできると思います。

ユーザに関しては Resource Access Management -> ユーザ -> 新規ユーザで。Administrator グループを作ってそこにterraformユーザをいれてあげる。そのグループに権限付与ポリシーでAdministratorをあてる、だったはず。まぁAWSのユーザ、ロール、ポリシーと同じノリです。

新規ユーザ作成時にkeyとsecretが生まれるのでそれを.envrcにいれて環境変数で読めるようにしましょう。

$ cat .envrc.sample
export ALICLOUD_ACCESS_KEY="secret_secret"
export ALICLOUD_SECRET_KEY="secret_secret"
export ALICLOUD_REGION="ap-northeast-1"

keypairですが、新規に作るのも面倒なので、自分のGitHubに登録してある公開鍵を使って https://github.com/chaspy.keys 既存のkeyをimportする形にしました。そのkeypairの名前だけterraformの keypair attachment resource にいれてあげる必要があります。

resource "alicloud_key_pair_attachment" "attachment" {
  key_name     = "key_pair_github" # Create key pair by hand
  instance_ids = ["${alicloud_instance.web.id}"]
}

Applyするとoutputにglobal ipがでるので、sshすればよいです。

余談だけど普段ラッパースクリプトとかCIとかでしかTerraform実行しないので terraform ってフルスペル入力するのしんどくてエイリアスした。。。

$ tf apply
(snip)
Apply complete! Resources: 11 added, 0 changed, 0 destroyed.

Outputs:

ip = 47.74.4.123

$ ssh root@47.74.4.123

Welcome to Ubuntu 18.04.2 LTS (GNU/Linux 4.15.0-52-generic x86_64)

 * Documentation:  https://help.ubuntu.com
 * Management:     https://landscape.canonical.com
 * Support:        https://ubuntu.com/advantage


Welcome to Alibaba Cloud Elastic Compute Service !

root@isucon8:~#

おそうじも簡単でらく。

$ tf destroy
(snip)
Destroy complete! Resources: 11 destroyed.

このあと複数台構成にするとかいろいろやるかもしれない。

次はAnsibleでApplicationを構築するところをやります。いうて以下を流すだけになると思うが。

github.com

おまけ

alicloud-providerに軽微なPR2件出した。マージされろー。

github.com

追記。された！

2019-08-18

delete branch botというGitHub Appをクローズした

はじめに

した。

github.com

ついにGitHubオフィシャルでPRをmergeしたあとbranchを削除する機能が出たからだ。

help.github.com

作ったときの記事

blog.chaspy.me

少し残念な気もするが、個人のリポジトリで1年弱、何の問題もなく安定稼働していたし、lambdaでまともになにか作ったのも、GitHub Appを作ったのもはじめてだったのでいい経験になった。

datadogでどれだけ呼ばれたかは監視をしていて、これを機に確認してみた。

f:id:take_she12:20190818131305p:plain

なにげに使用数は少しずつ最近は伸びていて、多いときに1日500回ほど呼ばれていたようだ。そういや会社の一部のリポジトリで「branchを消す文化」のないところがあったので入れたのもあったかもしれない。

このDashboardも削除した。

サービスだったりアプリケーションを「ちゃんと」クローズするのも大事だと思うので喜んでバイバイした。

またなにか誰かに使われるものを作れたらいいな。

2019-08-05

Terraform meetup tokyo#1を開催しました

はじめに

しました。

terraform-jp.connpass.com

ありそうでなかったmeetupだったので、思った以上に注目度が高かったようでした。しかし注目度だけが先走ったせいもあり参加率は悪く、具体的には書きませんが"最悪"の数字を叩き出したので次回以降は対策を練っていきます。

モチベーションが高いひと、これたはずだけど諦めたひとがこれないようなコミュニティにしたくない。

会場の様子。オイシックスさんの会場スケーリングできるからすごいんですよね。。。

f:id:take_she12:20190804233744j:plain

LTの様子。運営メンバー4名が発表しました。

f:id:take_she12:20190804233800j:plain

Hashicorpさんの"ハシ"を入手した運営メンバー。

f:id:take_she12:20190804233927j:plain

いつ使おう。まだ使っていない。

f:id:take_she12:20190804235235j:plain

Terraform-jpでは「せっかく勉強会に来ているのに何も話さないで帰るなんてもったいない（ありえない！）」という考えを大事にしており、ワールドカフェ形式でグループごとに話す取り組みに挑戦しました。

僕自身もやったことがなかったのですが、アンケートやTwitterを見る限り知見を得られた、来てよかったという声がいくらかあり、価値はあったようです。

懇親会で話していても、「1人でTerraformをしていて話せるひとがいない」というひとは結構な数いて、そういうのを支えあえる勉強会、コミュニティ（Slackを含め）であればいいと思いました。

また、飲食スポンサーはなんとHashicorpさんにお願いしました。申し分ない量のお酒とお菓子とつまみを提供いただき、また参加者にとっても有益であるTerraformの情報を話していただき、非常に助かりました。

meetup自体は今後も続けますので、今後もスポンサーをお願いする機会があればぜひに、という感じです。

Terraform-jpの"オフ会"はニッチなSource Code Readingと、meetup（Lightning TalkとWorld cafe）を隔月でやっていく予定です。なお実施日程は毎月最初の平日です。理由は特にないです。

次回 9/2 Source Code Reading#2

connpass.com

その次 Terraform meetup tokyo#2 10/1(火)です。よろしくおねがいします。LT公募します。

実際にコミュニティ駆動でaws providerにPRを出せて晴れてcontributorになれて本当によかったです。今後も仕事でDeepに使っていくはずなので、Contribution & より深い理解＆ Communityを盛り上げていきたいと思います。

Lightning Talk資料はこちら。まぁcode読むと怖くなくなるし最新verにするモチベあがるしいいことあるのでみんなでやろーぜ、ということを言いたかっただけの資料です。

言い損ねたけどこのコミュニティからContributor10人出したいなぁと思ってるのでやっていきましょう。

この業界に入って、Softwareの、Opensourceのコミュニティに、勉強会に助けられてきたので、それを提供する側にまわれて恩返しできたのが嬉しいです。

ぜひTerraformユーザの方は気軽に遊びにきてくださいね。それでは！

2019-07-17

Terraform aws provider PR / lambdaのnode engine v6.10のEOL対応

はじめに

github.com

mergeされた！

これはなにかというと、Lambda側でnodeのengine v6.10がEOLのせいでapplyにこけたので、テストとドキュメントを修正した。

もともとは別の aws_lambda_permission resourceのimport supportをやろうとしていた。

github.com

このページの以下のサンプル。

resource "aws_lambda_permission" "allow_cloudwatch" {
  statement_id  = "AllowExecutionFromCloudWatch"
  action        = "lambda:InvokeFunction"
  function_name = "${aws_lambda_function.test_lambda.function_name}"
  principal     = "events.amazonaws.com"
  source_arn    = "arn:aws:events:eu-west-1:111122223333:rule/RunDaily"
  qualifier     = "${aws_lambda_alias.test_alias.name}"
}

resource "aws_lambda_alias" "test_alias" {
  name             = "testalias"
  description      = "a sample description"
  function_name    = "${aws_lambda_function.test_lambda.function_name}"
  function_version = "$LATEST"
}

resource "aws_lambda_function" "test_lambda" {
  filename      = "lambdatest.zip"
  function_name = "lambda_function_name"
  role          = "${aws_iam_role.iam_for_lambda.arn}"
  handler       = "exports.handler"
  runtime       = "nodejs6.10"
}

resource "aws_iam_role" "iam_for_lambda" {
  name = "iam_for_lambda"

  assume_role_policy = <<EOF
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": "sts:AssumeRole",
      "Principal": {
        "Service": "lambda.amazonaws.com"
      },
      "Effect": "Allow",
      "Sid": ""
    }
  ]
}
EOF
}

runtime = "nodejs6.10"

ここね。

EOLになってるので The runtime parameter of nodejs6.10 is no longer supported for creating or updating AWS Lambda functions. という怒られが発生する。

aws.amazon.com

代わりに10.xが使えるので、古い世代をやめて1世代分送った感じ。

今回は実装ではないにせよ、ドキュメントの修正も大事な貢献だと思う。ちなみにaws providerのdocumentは website 以下にあるので気づいたらどんどんPR投げたらいいと思う。

github.com

おわりに

方針がよくわかんなかったのでとりあえずreplaceして投げたら丁寧にコメントくれて、その指摘に対応したらマージされた。

昨日からこのリポジトリのissue/PRをwatchしてるけど、かなりのスピードでReview/Mergeされていて、Hashicorpのcore committerたちしっかり働いています。いずれも24時間以内に反応もらえる感じです。

次は元々やろうとしてた lambda_permission のimportをやろうと思う。

ツナワタリマイライフ

日常ネタから技術ネタ、音楽ネタまで何でも書きます。

データ指向アプリケーションデザイン読書メモ：1章

信頼性、スケーラビリティ、メンテナンス性に優れたアプリケーション

信頼性

スケーラビリティ

メンテナンス性

まとめ

感想

datadog-aws-ec2-counter はべんり / OSSへContributionすること

はじめに

Pull Requestを送った

OSS にシュッとPRを送ること

おわりに

英語週報8/18~週

どうしたの急に

ゴールはなんだっけ

振り返り

Alibaba CloudにISUCONの模擬試験環境を構築する（Terraform編）

はじめに

delete branch botというGitHub Appをクローズした

はじめに

Terraform meetup tokyo#1を開催しました

はじめに

Terraform aws provider PR / lambdaのnode engine v6.10のEOL対応

はじめに

おわりに