docker compose で構築済みの開発環境に MySQL スレーブを追加したい

やりたいこと

docker compose で構築された mysql 環境にスレーブを追加したい。 (レプリケーションの遅延に起因するバグが報告されたので、開発環境で再現したい。)

チームに展開するので、手順は可能な限り簡単にしたい。

前提

以下のような環境が存在し、それなりにデータが入っている状態とします。

docker-compose.yml

services:
    master-db:
        image: mysql:5.6
        volumes:
            - ./master/data:/var/lib/mysql
            - ./master/conf.d:/etc/mysql/conf.d
            - ./master/initdb.d:/docker-entrypoint-initdb.d
        env_file:
            - ./master/master.env

master/conf.d/my.cnf

[mysqld]
log-bin = mysql-bin
server-id = 1

マスタとするため、 log-bin と server-id の設定が必要です。 (スレーブ追加時に設定しても問題ないはず。)

master/master.env

MYSQL_ROOT_PASSWORD=password
MYSQL_DATABASE=hoge
MYSQL_USER=master
MYSQL_PASSWORD=password

mysql スレーブを追加する

なにはともあれ、 docker-compose.yml にスレーブのサービスを追加します。

docker compose up すれば普通にサービス自体は追加されますよね。

docker-compose.yml

# ...
    slave-db:
        image: mysql:5.6
        volumes:
            - ./slave/data:/var/lib/mysql
            - ./slave/conf.d:/etc/mysql/conf.d
            - ./slave/init.sh:/usr/local/bin/init.sh
        env_file:
            - ./slave/slave.env

slave/conf.d/my.cnf

[mysqld]
server-id = 11

スレーブとするため、 server-id の設定が必要です。

slave/slave.env

MASTER_HOST=master-db
MASTER_USER=root
MASTER_PASSWORD=password

MYSQL_ROOT_PASSWORD=password
MYSQL_DATABASE=hoge
MYSQL_USER=slave
MYSQL_PASSWORD=password

通常の環境変数に加えて、マスタの情報である MASTER_* を記述します。

slave/init.sh

#!/bin/sh

mysqldump -h $MASTER_HOST -u $MASTER_USER -p$MASTER_PASSWORD --master-data --all-databases > /tmp/master.dump

until mysql -u root -p$MYSQL_ROOT_PASSWORD -e ''; do
  echo -n .
  sleep 1
done

mysql -u root -p$MYSQL_ROOT_PASSWORD -e 'STOP SLAVE'
mysql -u root -p$MYSQL_ROOT_PASSWORD -e "CHANGE MASTER TO MASTER_HOST = '$MASTER_HOST', MASTER_USER = '$MASTER_USER', MASTER_PASSWORD = '$MASTER_PASSWORD'"
mysql -u root -p$MYSQL_ROOT_PASSWORD < /tmp/master.dump
mysql -u root -p$MYSQL_ROOT_PASSWORD -e 'START SLAVE'

rm /tmp/master.dump

docker compose up で環境を立ち上げたあと、 docker compose exec slave-db sh /usr/local/bin/init.sh で叩きます。 ここでマスタからスレーブへデータをコピーし、レプリケーションの設定を行っています。

このスクリプトがキモになりますので、内容を順を追って説明します。

マスタからデータをダンプする

mysqldump -h $MASTER_HOST -u $MASTER_USER -p$MASTER_PASSWORD --master-data --all-databases > /tmp/master.dump

--master-data オプションでダンプする内容にバイナリログの座標を含めています。 (具体的には CHANGE MASTER TO MASTER_LOG_FILE = '...', MASTER_LOG_POS = ### が出力されます。)

MySQL :: MySQL 5.6 リファレンスマニュアル :: 17.1.1.5 mysqldump を使用したデータスナップショットの作成

スレーブにマスタ情報をセットする

mysql -u root -p$MYSQL_ROOT_PASSWORD -e 'STOP SLAVE'
mysql -u root -p$MYSQL_ROOT_PASSWORD -e "CHANGE MASTER TO MASTER_HOST = '$MASTER_HOST', MASTER_USER = '$MASTER_USER', MASTER_PASSWORD = '$MASTER_PASSWORD'"

マスタ情報を変更するため、 STOP SLAVE でスレーブを止めます。

その後、 CHANGE MASTER TO ... でマスタ情報(ホスト、ユーザ、パスワード)をセットします。

MASTER_HOST (及び MASTER_PORT)を変更するとバイナリログの座標がリセットされてしまうため、データをインポートする前に行う必要があります。

MySQL :: MySQL 5.6 リファレンスマニュアル :: 13.4.2.1 CHANGE MASTER TO 構文

MASTER_HOST または MASTER_PORT オプションを指定すると、スレーブは (そのオプション値が現在の値と同じ場合でも) マスターサーバーが以前とは異なっていると見なします。この場合、マスターバイナリログファイルの名前と位置の古い値は適用されなくなったと見なされるため、このステートメントで MASTER_LOG_FILE と MASTER_LOG_POS を指定しないと、そのあとに MASTER_LOG_FILE='' と MASTER_LOG_POS=4 が暗黙のうちに付加されます。

スレーブにデータをインポートする

mysql -u root -p$MYSQL_ROOT_PASSWORD < /tmp/master.dump
mysql -u root -p$MYSQL_ROOT_PASSWORD -e 'START SLAVE'

データに CHANGE MASTER TO MASTER_LOG_FILE = '...', MASTER_LOG_POS = '...' が含まれていますので、マスターのデータがインポートされると同時にバイナリログの座標が正しくセットされます。

これでスレーブ側のセットアップができたので、 START SLAVE でスレーブを再開させます。

おわりに

これらの変更によってファイル群を git pull で更新したあと、以下の手順でスレーブを追加できるようになりました。 スレーブ・サービスで1コマンド叩くだけでセットアップできるので、それなりに上手くできたかなと思います。

docker compose up -d
docker compose exec slave-db sh /usr/local/bin/init.sh

検証に使ったコードが↓にあります。

github.com

間違いや問題がありましたらご指摘いただけると幸いです。

※ 説明を簡単にするためにサービス同士の依存関係、認証、権限周りなどは簡略化してあります。実用する際はご注意ください。

参考

MySQL :: MySQL 5.6 リファレンスマニュアル :: 17.1.1 レプリケーションのセットアップ方法

デブサミ2020 Day 2

レガシーコードからの脱却

大事なことが多すぎて長めですm(_ _)m

  • 「レガシーコード」の定義は様々。ここでは「修正、拡張、作業が難しいコード」とする。
  • 「使われるソフトウェア」は変更が必要になる→変更できるように書いておく。
  • 品質は検査では上がらない。出来上がってから確認しても、品質の改善には繋がらない。
  • What と How を分離する。 How を指定してしまうと、選択や交渉の余地がなくなって創造性が発揮されなくなる。
  • ユーザーストーリーをベースとして会話する。知識はコード(テストコード)に落とし込む。
  • QCDS: Quality, Cost, Delivery, Scope の関係性。
  • Quality を下げると、後で埋め合わせが必要になる。リスクが高い。
  • Cost を調整するとは、人数を増やすこと。人月の神話からも分かる通り、上手くいかない。
  • Delivery を遅らせることは、普通はビジネスが許容しない。フィードバックも遅くなる。
  • Scope を調整することが合理的。短いスパンで少ないタスクをこなす。
  • ↑によって仕掛りが減らせる。完成したものにのみビジネス的な価値がある。
  • ↑によって素早く、多くのフィードバックが得られる。
  • 「良くないコード」は多すぎるので、「良いコード」について押さえる。
  • 名前が重要。汎用的な名前がついているものは疑わしい。
  • CLEAN Code を書く。 Cohesive, Loosely coupled, Encapsulated, Assertive, Non redundant の頭文字。凝集性、疎結合、カプセル化、断定的、非冗長。
  • CLEAN とテストで、バグ発見の時期を開発の終わりからもっと早い段階にもってくる。
  • テストのしやすさが品質を測る基準になる。
  • 素早く働くということは、綺麗に働くということ。5S は開発におけるコードや物理的な環境についても適用される。

ひたすらに同意しか無いお話でした。

レガシーコードからの脱却 | Ryuzee.com

デブサミ2020【14-C-1】レガシーコードからの脱却 #devsumiC #devsumi - Togetter

プロダクトを10年運用するチームをつくる

はてなさんで実践している内容ですね。

  • 「動いているシステムはさわるな」は現代では通用しない。現代のシステムは常に自動で更新され続ける。
  • システムを更新し続けるためには「CI/CD」「監視」「DevOps」の整備が必要。
  • 人も入れ替わり続ける。この業界は学生の部活よりも入れ替わりが頻繁かも。
  • 人の入れ替わりに対応するために、はてなでは「スキルマップ」「障害対応演習」「式年遷宮」を利用している。
  • スキルマップの効果。チームのスキルバランス可視化、リスクの察知、チームから失われたスキルの気付き、学習目標の指針。
  • スキルマップを維持するコツ。評価に使わない、他チームと比べない、粒度を気にしない、定期的にメンテする(振り返りでメンテする。振り返りやってないならやった方が良い)。
  • 障害対応は属人化しやすい。新規メンバーは入っていきづらいし、緊急事態なので教育の余裕がない。
  • ステージング環境をわざと壊して、慣れていないメンバー中心で復旧させる。避難訓練。
  • 半期に一回ぐらい、スキルマップで弱いところを壊す。また、実際の障害直後に当日対応しなかった人を対象として行う。
  • 一定のタイミングでシステムの根幹(アーキテクチャ、FW、データストア等)に手を入れる。式年遷宮。
  • ↑技術的負債の返済、モダンな環境への適応、エンジニアの技術継承(人の入れ替わりへの対処)が目的。
  • 現実の式年遷宮とは違って、フルスクラッチはしない。しないためのエンジニアリング。

実際に業務で取り組んでいる内容を話してもらえるのは大変ありがたいですよね。

プロダクトを10年運用する チームをつくる / DevSumi2020 - Speaker Deck

デブサミ2020【14-B-4】プロダクトを10年運用するチームをつくる #devsumiB #devsumi - Togetter

オープンソースのこれまでとこれから

個人的には「Jenkinsの人」である川口さんのお話です。

  • 「懐かしいですねぇ、XML」
  • OSSは慈善事業ではない。今ではユーザ企業(自社プロダクトを開発している企業)の技術がOSSとして出てくる。
  • 同業他社と協調してやっていくことで、コストが圧縮されるなど全体としてどちらにも利益がある。求人活動の一環にもなっている。
  • 開発者だけでのOSSは難しい。キレイなwebサイトとか作れない。マーケッターなどの協力が必要。

オープンソース愛に溢れたセッションでした。

デブサミ2020【14-C-6】オープンソースのこれまでとこれから #devsumiC #devsumi - Togetter

デブサミ2020 Day 1

今年もモチベーションをもらいに行きました。

最新のブラウザで変わるCookieの取り扱いやPrivacyの考え方

最近色々と動きがあるブラウザ周りのトピックの一つ、Cookieのお話。

最近の流れ

ブラウザ「最近トラッキングが目に余る、プライバシーに配慮しないと。対策として 3rd party cookie を無視しよう。」

トラッキング「js で document.cookie に直接書き込んで 1st party cookie 扱いにしてやるぜ。」

ブラウザ「それも制限かけるわ。1日しか保存しないとかな。」

トラッキング「 CNAME でサブドメイン切ってもらって 1st party cookie にするわ。」

ブラウザ「うーん、もっと厳しくしていこうかな…、 CNAME だったらブロックするとか…。」

イタチごっこの様相を呈している模様。

これから

Cookie はセッションとかシンプルな用途に限定して、トラッキングは必要最低限の情報を専用の仕組みで追えるようにしようという取り組みが起こっているとのこと。

最新のブラウザで変わるCookieの取り扱いやPrivacyの考え方 - Speaker Deck

デブサミ2020【13-C-1】最新のブラウザで変わるCookieの取扱いやプライバシーの考え方 #devsumiC - Togetter

ぼくらの六十日間戦争 ～オンプレからクラウドへの移行～

わりと好物のオンプレからクラウドへの移行話。実際の業務で上手くいった事や失敗した事を共有してもらえるのはとてもありがたいですね。

  • 「手のかからないインフラにしたかった」
  • 移行手順は事前に何度もリハーサルした。移行作業自体はスムーズに終わった。
  • 連休明けの6日目、CPU使用率が天井に張り付く。特定のクエリが重い。
  • クエリプランがおかしくなっていた。統計情報の更新をしていなかった。インデックスが断片化していた。
  • 「データベースは移行前に身を清めておく必要がある」
  • 移行第二弾では、オンプレの本番環境に再生可能な Trace を仕込んでおき、テスト環境で擬似的に1ヶ月運用分のパフォーマンス検証を実施した。
  • 「トラブル対応は祭り。積極的に参加してスキルやシステムの知識を身に着けよう」

スライドの示し方やゆっくり丁寧な話し方など、とても聴きやすかったです。

Our60DaysWar-MigrationFromOn-premiseToCloud - Speaker Deck

デブサミ2020【13-D-2】ぼくらの六十日間戦争 ～ｵﾝﾌﾟﾚからｸﾗｳﾄﾞへの移行～ #devsumiD - Togetter

質とスピード

言わずとしれた twada さんのセッション。ソフトウェア開発においては質を犠牲にしてもスピードは上がりませんよというお話。

  • 「品質を犠牲にする」 というのは紐解くと「保守性を犠牲にする」ということ。
  • 「後で綺麗にすればいい」その「後で」は訪れない。市場からのプレッシャーが弱まることはない。
  • 逆にスピードを落としても保守性は上がらない。スキルに依存する。つまり、スピードと保守性はトレードオフの関係ではない。
  • 「要はバランス」という言葉が出てくる場合、それは深堀りしきれていないということかもしれない。
  • 「品質は実質無料」品質を上げるコストは手戻りの減少等の効果によって回収できる。
  • コードの品質を高く保つ「からこそ」速い。質がスピードを生み、スピードが質を生む。
  • 「短期的には速い」の「短期的」は、自動テストで言えば「4回」である。内部品質への投資が回収されるのは1ヶ月である。
  • つまり、品質を高める投資は自分たちが受益者となる。道徳や矜持の話ではない。
  • 削るべきは現実的に考えてスコープ。リリースを延期してもよいが、その場合はフィードバックが遅れる。

圧倒的納得感です。

質とスピード（2020春版） / Quality and Speed 2020 Spring Edition - Speaker Deck

「要はバランスおじさん」のまとめ - Togetter

デブサミ2020【13-B-4】質とスピード #devsumiB #devsumi - Togetter

Hondaの生産技術屋さんがソフトウェア開発でアジャイルを初導入し組織変革に挑戦

ホンダエンジニアリングさんでアジャイルを導入したお話。 

  • 「動くソフトウェアこそが、要求を洗練させる最も優れた表現方法である」
  • 変化には暇人が必要。
  • (アジャイルをやるには)組織文化と雑務が邪魔。
  • 失敗するならすればいい。短い期間で区切っているので、上手くいかないやり方だったなら捨てればいいだけ。
  • 口出ししたいことはあるが、あえて失敗するまで見守ってから得たものについて振り返る。トライ・アンド・エラー。

世間一般でイメージされる Honda らしさと違う状況になっていて、それを改善していくという現在進行系の内容でした。

デブサミ2020【13-B-6】Hondaの生産技術屋さんがソフトウェア開発でアジャイルを初導入し組織変革に挑戦 #devsumiB #devsumi - Togetter

Visual Studio 2019 Launch Event in Tokyo. に行ってきました。 #VS2019

connpass.com

お仕事はもっぱらC#で.NETなのにあまりそっち方面のイベントに参加したことがないことに気付いたりしたので申し込みました。

 大人の事情でお仕事に使っているのはまだ2017ですが、軽くなったとかAIによる入力補完とか楽しそうな情報が流れてましたよね:)

 品川はさっぱり縁がないですね…;

Visual Studio 2019 GA ! ～ 最新情報 & これからの開発スタイル @chack411

タイトル通り、VS2019でサポートされるこれからの開発で利用される機能についてのセッションでした。

最近DockerのWindowsコンテナがマイブームなので、AKSで一部のコンテナだけ(？)自分の開発環境のものを使って他は共有するテスト環境のコンテナを利用できる機能みたいなのが気になりました。

関わっているプロジェクトのDockerfileを勝手に書いたりしていて本番運用できるかどうか考えてみたときに、AWSだとWindowsコンテナが自前で頑張るみたいな感じだったので早々に見切りをつけてしまったのだけれどAzureならうまくできるのだろうか。(そもそもコンテナで運用するほどの規模じゃなさそうという話はあるけれど、半分趣味でやっている。)

 

www.slideshare.net

.NET Frameworkのプロジェクトを.NET Coreにマイグレーションする勘所を実際にやってみて説明していただけるという内容でした。プロダクトコードを使ってデモしていただけるのは具体的にイメージがつくのでとてもありがたいですね🙏🏻

「.NETのメインはもうCoreに移ってる」とのこと。バージョンアップもまずはCoreに入っていくし、複数バージョンが同居できるし、ランタイムごと配布できる。

確かにポータビリティがあるというだけで充分に魅力的ですよね:) 顧客の.NET Frameworkバージョンに縛られていつまでも古いバージョンを使い続けなければいけない苦しみ…肌で感じております…:(

CoreのプロジェクトからFrameworkのプロジェクトを参照していてもビルドできて実行も可能とのこと。ただしFrameworkにあってCoreに無いAPIは普通にあるので実行時に落ちる可能性がある。実際にそのようなAPIが呼ばれるコードパスを通らないと発覚しないので、できればやらない方がいい。

もちろんやらない方がいいに決まっているわけですが、現実的には全てのプロジェクト/ライブラリを同時に置き換えるのが難しいことはあるわけで、そういうところは現実に寄せて実行可能としている姿勢は.NET系の文化としてあるのかなと勝手に思ってます。そういう守るところは守りつつ現実的な妥協(？)もやっていくバランスがとっても良いと感じてます:)

実際にCoreへマイグレーションするのにどれぐらい修正が必要なのかは.NET Portability Analyzerを使うとわかるとのこと。サードパーティ製のライブラリはサードパーティに対応をおまかせするしかないとのこと、そらそうだ。

ところでお話の中でオススメだと言及されていたSimple Injectorが気になるので後日触ってみたい。

 

www.slideshare.net

先述の通り最近DockerのWindowsコンテナがマイブームなので注目だったのですが、知識が足りずにあまり咀嚼できませんでした;

docker-compose/Service Fabric/k8sあたりのオーケストレーション(？)周りはまだ全然触れていないので、個人的な今後の課題ですね。

C# 8.0 Preview in Visual Studio 2019 (16.0) @ufcpp

「C#といえば」の岩永さんのセッションでした。C＃erの例に漏れず、私も大変お世話になっております🙇🏻‍♂️ブログでも紹介されているC#8.0の新機能についてわかりやすく解説されていました:)

NRT(Nullable Reference Types null許容参照型)はオプションによって有効/無効を切り替えられるとはいえ、原則として後方互換を破壊しないというC#の原則を破ってでも入れたい修正とのこと。(オプションで切り替えるのは構文が分岐するということで複雑性が増すので、それも原則としては避けていたらしい。)

確かに今まで遭遇したことがない機能追加ですよね。とはいえ確かにnullを排除するのはモダンな言語では避けて通れないお話だと思います。私も正式リリースの暁にはチャレンジしたいです:)

とはいえnull許容なライブラリを使った瞬間に許容/非許容が混ざるので、混在するのは前提でnullチェックなどはしていかないといけないとのこと。もともとnullありきで設計されている以上、そこは仕方ないですよね。

インターフェイスのデフォルト実装はランタイムの変更が必要になる機能ということで、これは.NET Framework 2.0(2005年)以来のことだそうです。メジャーバージョンアップにふさわしい機能追加ですね:)

他にもswitch式やそれと組み合わせられるパターンマッチング、null合体代入など嬉しい機能が目白押しですね:) 大人の事情でValueTupleとデコンストラクタすらまともに使えていないですが、正式リリースが楽しみです:)

 じゃんけん大会でステッカーなどもらってお開きとなりました:) MacBook Proにステッカー貼りまくり野郎なのですが、いい加減に空きスペースがなくなってきたのでアップルロゴを隠す形で貼りました;

C#の新機能の話はやっぱりテンションが上りますね^^; 思えばオライリーさんのC#本を読んで触り始めてからずっと好きな言語です。なんというか、カチッとしてるけれども現実に折り合いをつけられる柔軟性を持っているというか…。モダンな機能もどんどん取り込まれますし、Coreの登場で間口も広がりましたしね:)

今後もC#でお仕事を続けていきたいです:) なので自分から環境を変えていこうと改めて思いました。

運営に関わられた皆さん、ありがとうございました🙏🏻

デブサミ2019に行ってきた #devsumi

今年もモチベーションとか色々もらいました:)

例によって印象に残ったセッションを記録です。

Day 1

 Wi-Fi本当にありがたいです🙏🏻

 

GitHub Actionsはどのような未来を描くのか : コンテナ技術が開くワークフローのOSS化 

Speaker Deck @ikeike443

タイトル通りGitHub Actionsについてのお話。

- ワークフロー=アクションの組み合わせ

- アクション=1コンテナ

- アクションの実態はDockerfile

- Dockerでできることは大体はできる

- イベントが色々用意されていて、外からキックすることもできる

- 既に用意されているアクションも色々ある(HTTP叩いたり

楽しそう(小並感。

ベータの申込みをしたので通ったら触りたい。

 

レガシーとのいい感じの付き合い方 〜15年続くウェブサービスのシステム改善パターン〜

自分のお仕事は結構な割合でレガシーとのお付き合いなので、共感と学びが多いセッションでした。

特に「葬り(不要な機能の削除)」が大事というのは本当にそうだと思います。機能が多いということはリファクタリングするにあたって気にすることが多いということで、不要な機能を残すために気を使うというのは労力的にも気力的にも大変苦しいことですよね…。顧客に「不要」だと認めてもらうスキルが必要だと痛感したことがあります。

 あとは「自分たちでコントロールできるインフラがあると進みが早い」というのも大いに共感できます。これがあるとスクラップ&ビルドも簡単で色々な試しができてスムーズですよね。この観点でIaaSがもたらす恩恵は大きいなと感じています。

 

カオス化した組織とエンタープライズシステム群を、モダン化したい！ノンIT企業のシステム企画開発を、ドメイン駆動型に組織ごと変えるまでの道のり

涙なくしては聞けない、素晴らしいお話でした。あるあるすぎて首がもげそうになる。(心を打たれすぎてろくなことを呟いていない…)

9人で9事業をカバーしてたけど21人で4事業にとか、どうすれば可能なんだろうか…。

「運用・問い合わせはイイヤツに集まる」ありすぎて切ない…。

障害が発生すると保守が回らないので保守、障害対応、パフォーマンス改善に体制を分割した。集中が必要な業務と割り込みが発生する業務を兼任するとどうしようもなくなるのでこれは絶対に分けないとですよね。

外部の会社と仕事をするために「俺流」を捨てる。これも本当に大事だと思います、盲目的に世の中の標準に従えばいいということではもちろんないわけですが、標準はなるべくして標準になっているわけですよね。

あとはいろんな情報を数字として出せているのがすごいですね、見える化ができている…。

ドメイン駆動で「価値の低いドメインは放っておこう」という判断になるのは先程の「葬り」と似てますよね。優先順位をつけるのとやらない判断をするのは本当に大事だと思います。

(C#の会社らしいので個人的にちょっとシンパシーを感じました)

 

「ITエンジニアに読んでほしい！技術書・ビジネス書大賞 2019」プレゼン大会

割と毎年参加しているので今年も:)

もちろん全部の本が良書なのだと思いますが、個人的に刺さったのは「イシューからはじめよ」の「それは本当にイシューなのか？」という問いかけです。

他のセッションでも出てくる「不要な機能」「価値の低いドメイン」と同じように、イシューを磨き込んでいると「これは対応しなくて良いものでは？」となることは意外にあると思います。対応しないという判断を伝えると「サボりじゃないの？」と思われてしまうことがあるので、そこはそうじゃないということを共有していかないといけないですよね。

 

Day 2  

ノートの充電を忘れてピンチだったが、空き時間にラウンジで充電できたので事なきを得ました🙏🏻

 前日伺ったらあんまり残ってなくて「明日の朝来てもらえればあると思います！」とのことだったので早々にゲットしました:)

 

 ソフトウェア開発の「今ココ」に適応するために― カイゼン・ジャーニーから見つかった新たなfunと前進への旅路 ―

カイゼン・ジャーニーから見つかった新たなfunと前進への旅路 - Speaker Deck

我々に越境できない境界は無い。

 技術書大賞でもプレゼンされていたカイゼン・ジャーニーについてのセッション。情熱が伝わってくる内容でした。

「フレームワーク主導NG」はその通りですよね。まずは悩みや課題に注目して、それを解決する手段としてフレームワークが存在する。

 コミュニティが「野戦病院」というのはなるほどそのとおりだなと思いました。傷を癒す場所ではあるけど、居場所ではない。戻る場所がある。「組織を超えた学びの場」確かに必要だと実感しています。

 買いました:) 付箋も貼らせてもらいました:)

 

Site Reliability Engineering at Google

タイトル通りGoogleさんのSREについてのセッション。

SREは業務時間の50%以上を開発やシステム安定化に関わる業務にあてるというルールがあり、それを脅かすようなシステムの運用は開発チームに突き返す権限を持っている。それによって開発チームが安定したシステムを構築する動機付けができて、SREも開発チームが安定したシステムを開発できるように支援する形になる。非常に理にかなった仕組みですよね。

これを回すには「安定している」を共通認識として定義しないといけない。それは「SLOが満たされている」ということ。SLOを満たすために「エラーバジェット」を使う。エラーバジェット=1.0 - SLO。エラーバジェットを超える=安定していない。

エラーバジェットを超えそうになったら新機能のリリースをフリーズしてシステムの安定化に注力する。それで納期が守れなくなったりするならば、それはSLOの設定がおかしいということ。SLOが100%ということは1回でもエラーが発生するとエラーバジェットを超えるということであり、そのような設定はおかしい。SLOの設定は非常に難しいので、運用しながら調整していくもの。

デベロッパーの「Burnout(燃え尽き症候群)」を防ぐことが大事。つまらない仕事をさせていると燃え尽きてしまう。それを防ぐための50%ルール。「Toil(労力のかかる作業)」を削減することが大事、Toilは悪。

障害対応が終わった瞬間に「Postmortem」を書く。発生要因、対応時の反省点、改善策などを文書化する。記憶のダンプ。個人を非難するような内容を絶対に書かないこと、それは個人のミスを誘発するシステムを設計したチームの責任。言い訳のための文書ではなく、知見の蓄積である。

知見に溢れたセッションでした…。

 

 まとめ

今年は例年に増して共感できるセッションが多かったような気がします。

もらったものを糧にして頑張っていきたい所存ですね…。

 ラウンジで糖分不足にうめいていたら飴ちゃんもらいました:) ありがたし。

#yapcjapan YAPC::Tokyo 2019に行ってきた感想

yapcjapan.org

Twitterで開催するのを知って、「YAPCなら行かねば」とその場でチケットをポチったので行ってきました。場所が浅草橋ということで、旧職場に近くて懐かしかった…。

 建物は外から何度も見ていたけど、入ったのは初めて。

f:id:NYamairi:20190128115005j:plain

ワイヤレスチャージャー

ノベルティがトートバッグ、Tシャツ、ワイヤレスチャージャーと素敵揃いでした:)

(「明日こそやります」缶バッジが見透かされてる感があって良い感じ。)

 

チームが前に進み続けるために僕たちが考えたこと / YAPC::Tokyo 2019 - Speaker Deck @__papix__

プロジェクトを進めるために何をどう変えてその理由はなんなのか、丁寧に書かれていて参考になりました。

"業務・開発フローは「変えることは無条件に正しい」くらいに思って良いと思っています。" @songmu

これは本当に勇気をもらえる素敵な言葉ですね。銀の弾丸が存在しない以上、常に良いやり方を模索していくのが大事なんだろうと思います。

今いる現場で何をどう変えれば良い方向に行けるのか、引き続き考えていくモチベーションがもらえました。

 

私とOSS活動とPerl @duck8823

聴いていてとても良い話だなと感じました。

自然にPerl(プログラミング)に出会って、自分で課題を解決するためにモジュールを書いて、コードを(自宅と職場で)共有したいからGithubに上げて、モチベーションを見つけてCPAN Authorになって、フィードバックをもらってモチベーションが上がって、それによって新しいスキルが身について、勉強会につながってそれが転職のきっかけになって、採用の決め手として自分がやってきた事が評価される。

すごく素敵なことだと思います。そしてそれを共有してくれてとてもありがたい。

 

 

Perl to Go - Speaker Deck @xaicron

Goは A Tour of Go をやった程度しか触っていないのですが、ちょっとPerlっぽいなと思った覚えがあります。(mapを触ってて思ったのかな？)

Perlはガッツンガッツン連想配列を使ってネストするイメージですが、Goはstructを使ってちゃんと型を意識していけるのでより素敵かもですね。(Perlの気楽さも嫌いではないです。)

識別子名の頭文字が大文字か小文字かでpublicとprivateを区別するのが面白いなーと思ってます。名前だけで一目見ればわかるのは良いですよね。

あとはinterfaceの実装を明示的に行わないのも面白いですよね。interfaceと同じシグネチャのメソッドを全部実装していれば実装している扱いになるというもの。Rubyを初めて触ったときに出てきたダックタイピングを思い出しました。

 

 ランチ

 行こうと思ってたつけ麺屋さんは移転してました:(

卓上にリンゴ酢が置いてあって、麺にかけると素敵な風味になるのです:)

 代わりに別のラーメン屋さんへ行きました:)

こちらはおじいちゃんおばあちゃんが夫婦でやっているお店で、チャーシューが1cmぐらいの厚さのブロックで美味いんです:)

浅草橋には他にもじゃじゃ麺とかトンカツとかで美味しいお店があるので、また機会があれば行きたいですね〜。

  

２つのDXと技術的負債-YAPC Tokyo 2019 - Speaker Deck @hiroki_daichi

エンジニアリング組織論への招待 の著者。すごくためになるお話でした。

  • 不確実なものから人は闘争・防御・回避しようとする
  • 人間が本質的にわからない(不確実な)ものは未来と他人
  • 未来には実験による仮説検証で対応する
  • 他人にはコミュニケーションで対応する
  • コミュニケーションは他人が知っていて自分が知らないもの及びその逆のギャップを埋めるもの
  • ソフトウェアづくりはコミュニケーションそのもの(プログラミングは機械が理解できるほど明晰な言語化)
  • 悪い組織構造は悪いシステムを生み出す
  • エンジニアと非エンジニアではシステムに対して見えている情報量にギャップがある
  • 組織をリファクタリングすることでそのギャップを埋める

説得力しかなくて大変わかりやすかったです。

 

YAPC::Tokyo 2019 Log Friendly DB Design - Speaker Deck @fist0

変更履歴をとっておく必要があるデータ(口座残高など)を保持するためにどのようなDB設計が良いのかというお話でした。

今も保守してる私がDB設計したシステムも変更履歴を持っているのですが、1履歴ごとに有効範囲をカラムで持つようにしちゃって取り出しに苦労しているので他の設計が良かったんだろうな〜と後悔してます…。

 

 YAPCはキャリアがPerlで始まったということと、自分から初めて参加したカンファレンスということで思い入れがあります。Perlのコミュニティが持つゆるい空気も好きなので、また参加したいですね:)

#builderscon 2018 2日目

 

nyamairi.hatenablog.jp

 

昨日ちょっと満たされた部分が尻上がり的に満たされていってだいぶ元気になった。やっぱり自分から環境を変えていかないとですな。

「早めに着いたら謎ガジェットをいじって遊ぼうかな〜」などと考えていたが、案の定モーニングを食べる時間が確保できたぐらいだった。(PCを開いている辺りに痕跡が見える。結局この日は謎ガジェットを触る余裕は無かった…。)

あとやっぱりブログはその日のうちに書かないと勢いがなくなりますね、はい。

全てのエンジニアに知ってもらいたいOSの中身について - builderscon tokyo 2018

わりとざっくりした認識で使ってる自覚があるので。

「クラウドとかDockerとか出てきてあんまりOSを意識しなくなったよね？最後にOSのインストールをしたのはいつ？」というような導入だったと思います。確かに。

CPUの歴史とかは結構楽しかったけれども、途中からは結構わからない単語が頻出したりしてついていけなくなってしまった…。前提知識的にもっと優しいところから入らないと私には厳しいかもしれない。

あなたの知らないデータベースのロギングの世界 - builderscon tokyo 2018

お仕事でガッツリ使っている割には意識できていない。

実際に運用で使っているお話かと思いきやまだ試してる途中的な内容だった。なので未完。

DB自身でログを吐くとI/Oの負荷が辛いのでProxySQLでやっている。キャッシュとかルーティングとかFirewallとかの機能があるらしい。しかしドキュメントが整備されていないとか、ProxySQL自身でアカウント情報を持っていてバックエンドのそれとズレるとダメとか、charsetがクライアント/ProxySQL/バックエンドの3層で考慮が必要になるとか、ProxySQL自体も大分辛そうである。

そういえばあんまり関係ないけど、前社(10年以上前？)では書き込みはPostgreSQLで読み込みはMySQLという構成のプロジェクトがあって、PostgreSQLの書き込みクエリをMySQLに流すようなことやってて色々辛い部分があったなーと思い出した。(なぜそういう構成だったかと言うと、「PostgreSQLの読み込みパフォーマンスがイマイチ。PostgreSQLのトランザクション性能は欲しいけど読み込みのパフォーマンスはMySQLが欲しい。」のような理由だったように思う。当時はペーペーだったのであまり突っ込んで議論できるような感じではなかった。) 

ブログサービスのHTTPS化を支えたAWSで作るピタゴラスイッチ - builderscon tokyo 2018

ピタゴラスイッチ好きです。

Let's Encryptのおかげで大量の独自ドメインに対してHTTPS化することができたとのこと。LE素敵。

万単位の証明書を全部読み込むとメモリと起動時間がエライことになるのでリクエストの度に証明書を読み込むようにしているとのこと。すげえなそんなこと考えたこともない。ngx_mrubyで証明書の読み込み時に動的に証明書を読みにいくという単純な話らしい。nginxさんってそんなことできるのね…。

ピタゴラスイッチは発行の方だった。メモ書きがめっさ多くて全部大事なことっぽい…。

要は「1つの処理(Lambda)でやることを単純にしてワークフロー(StepFunctions)でつなぐ」というのが大事ということだと思う。処理単位を1ドメインにして単純にする。複数ドメインを同時に扱うと「1つ失敗してほかは成功したけど、これって処理全体としては成功なの？失敗なの？」となってモニョる。

1つの処理を単純にした方が良いのはわかるけど、それをつなぐワークフローを構築するのが面倒なのでつい色んなことを1つの処理でやっちゃうんだと思う。そこを簡単にするためにStepFunctionsとかを使うといいということなんだろうな。なのでそういうものがあると知っているのは大事なんだろう。

証明書を保存しているDynamoDBのTTL Triggerで証明書の更新フローを起動するのはなるほどなーと思った。

Using Chrome Developer Tools to hack your way into concerts - builderscon tokyo 2018

デベロッパーツールは上っ面でしか使ってないので。懲りもせず英語を聴こうとする(しかも同時通訳のレシーバを借り忘れた)。

内容としては「動画が再生された回数のカウントをハックされないようにするには〜」という感じ？Chromeのデベロッパーツールを使ってハックしてみて、そこからハックを防ぐ方法を考えるみたいな？

XHRのリプレイ機能とかリクエストを出したコードにジャンプするとか、恥ずかしながら知らなかった…便利そう…。

RDB THE Right Way ~壮大なるRDBリファクタリング物語~ - builderscon tokyo 2018

なんかRDBの話って好き。そーだいさんだし。さすがのベストスピーカー。

論理設計と物理設計の違い。ERDの立ち位置。モデリングとは。データと情報の違い。自分の認識と全然違ってめっさありがたかった。そうか…ERDって論理設計で使うものだったのか…物理設計だと思ってた…。

Entityの話。イベントとリソース。この辺りは以前別のところでも聴いたことがあるのだが、結局はっきりとはわかっていない。イベントは事実で過去。リソースはそれ以外。何度も唱えたり資料を読んだりして理解したい。

「RDBMSの機能は奥の手」これはわかりやすい。奥の手をいきなり披露するのは悪手ですよね。「今日正しい設計が来年正しいとは限らない」いつの間にかインデックスは貼らないとまともに動かなくなったりね。

このセッションも大事なことがいっぱいあって書ききれない。最後の方は指数関数的にエモくなって終わった(素敵)。

Lightning Talks - builderscon tokyo 2018

色々面白かったけれど、Next Editor に圧倒されてしまった。パない。こういうゴリゴリな感じは憧れる。

Closing - builderscon tokyo 2018

今年も楽しかった。サポーターチケットにしてよかった(謎ガジェットもらえたし)。

改めて自分から環境を変えていかないとなと感じた。環境を変えるのはしんどいけど、楽しくない環境もしんどいので頑張っていきたい。