YAPC2015に行ってきました
Japan Perl Association 主催での最後のYAPCということで、今回は個人スポンサーで参加させて頂きました。
聞いたセッションは、
Consulと自作OSSを活用した100台規模のWebサービス運用
- ConsulをDNSとして使用することと、自作デプロイツールの話し。
- Consulの可用性について。3台 or 5台
- Internal向けの名前解決の問題
- 当時は、Route53にInternal向けがなかった
- 動画変換はマネージドサービスは高いので、スポットインスタンスにしている
- デプロイの問題。pushではオートスケールに対応できない。pullではビルド中に取りにこられる可能性がある
- 弊社ではinit.dにpullする処理を書いてある。。。
- 解決する為に作ったのがStretcher
- ビルド後にtarボールをS3へ。各ノードへconsulでイベント発信とキャッチ。
- オートスケール時は、スケールされたホストが最新のmanifestを取得。自分自身にイベント発信してデプロイ。
- 作成に要した時間は1weekくらいだとか。
Perlの上にも三年 〜 ずっとイケてるサービスを作り続ける技術 〜
- はてなでの内部品質改善のお話し。
- フレームワーク仕様で継承されていると、superクラスの実装確認しないといけないので大変だった。
- 類似メソッドで溢れていたので、使っちゃダメなメソッドの共有。
- 継承しない。SQL手書き。薄いフレームワークで素早く。
- コピペ3回で共通化。DRY3(笑) Common:: から Service:: に。
- なぞの書籍の宣伝(笑)
- メソッドの処理は不変なので、入出力で事前事後条件を考えておくべき。
- 例)事前:スタックに空きがあること。事後:スタックに積まれる。サイズが1増える。スタックが空ではない。
- エンティティ(状態を持つ)と値オブジェクト考えると整理しやすい。
- 値オブジェクトやServiceは状態を気にする必要がない。
- ユキビダス言語を策定している。
- (感想)継承しない。薄いフレームワークは賛同ですが、時にtemplate methodなど使用すると結果的にコード量が減り、コード体系が統一化できる時もあるけど、その辺どうなんだろう。。。
うっかりをなくす技術
- ヒューマンエラーについてのお話し。
- ヒューマンエラーの要因は、人的要因、マネージメント要因、環境要因によって引き起こされる。
- 人的要因は注意力(指差し呼称)や、過去の経験によって回避できることもある。
- マネージメント要因は十分でないディレクションや、レビュー不足によって。ワークフローの改善や自動化、ドキュメンテーションの整備などをがんばろう。
- 環境要因は何はともあれ複雑な仕様やインフラ、手順をシンプルに。
- 気づいていないヒヤリハットは想像以上に多い。実際に被害がないので、気づきにくい。
- git hubのissueに記録すると管理しやすい。
- 「シンプルに書く」についてリーダブルコードの紹介。
- ミスの予防についてstrict.pmやwarnings.pm を使おう。
- (感想)あとはテストコードとかも効果的に使える吉かな。