golang.tokyo #3 に参加してパフォーマンスの話を聞いてきた

先週 golang.tokyo #3 に参加した．抽選倍率2倍だったからダメかもなぁ…！と思って申し込んだら当たった．

テーマは「パフォーマンスチューニング」だったけど，「パフォーマンスチューニング」とは違うような話もあった．エウレカの話も聞きたかったから残念！

golangtokyo.connpass.com

Accelerating real applications in Go @cubicdaiya

• GitHub - kazeburo/chocon
  • Golang 標準の net/http で簡単にプロキシサーバを立てられる
  • ただ細かくパラメータをチューニングするためには net/http/client.go と net/http/transport.go を使う
  • 特に MaxIdleConnsPerHost はデフォルト値 2 だから小さくなっている
• GitHub - mercari/gaurun: General push notification server in Go
  • goroutine 数やチャネルのサイズをメトリクスとして取得できるようにしている
  • モニタリングできるようにしている

メルカリのプロダクション環境に導入されているソフトウェアの話で非常に深かった．パパあるあるだと思うけど「チョコン」って聞くと「コッシーの友達のチョコン」のことを考えてしまうので，発表中に変にニヤニヤしてしまった…w

• Accelerating real applications in Go

PERFORMANCE OPTIMIZATIONS / Carlo Alberto Ferraris

• サーバ費用より人を雇う方がコストが高い
• オプティマイズするよりスケールアウトした方が良い
• The Twelve-Factor App
• 失敗する前提で考える

Golang の話ではなく，サービス開発の思想的な話だった．途中から Golang の話しになるのかなぁーと思って聞いてたらそのまま終わった．話は凄く面白かった．

Stream の扱い方 / jun06t

• ioutil.ReadAll で全て []byte に変換するとメモリを食ってしまう
• io.Reader と io.Writer を引数としている場合は Stream のまま使うと良い
• API リクエストを decode する場合 json.Unmarshal でなく json.NewDecoder を使うと高速になる

1番テーマに沿ってる気がした．実際に同じようなコードを書くときがあったら気を付けたい．今回 Slides ってサービスが多かったけど，人気なのかな？あまり見たことがなかった．

git-schemlex と ddl-maker を使った DB migration の紹介 @Konboi

• Golang 製のマイグレーションツールは多くある
• 基本的に全て Rails 方式
  • マイグレーションごとにファイルを生成して up / down で実行できる
• 大きな開発が複数ライン並行で走るときに厳しくなる
• GitHub - soh335/git-schemalex: database migration tool for mysql schema is managed via git
• SQL の差分を生成して実行してくれる

タイミング良くマイグレーションツールの調査をしていたので参考になった．Golang 製だと Goose も人気かなと思うけど，既存スキーマに対してエクスポートができないという点に困ってて，うまく運用にハマる気がしてない．そうなると Ruby 製だけど GitHub - thuss/standalone-migrations: A gem to use Rails Database Migrations in non Rails projects かなぁ…と考えているところ．

speakerdeck.com

database/sql とコネクション / Talos208

• database/sql を使う場合 db.Close() はするべきではない
• 1度 Open したらそのままにして Open と Close のコストを下げることができる
• ソースを追うとよくわかる
• Golang 1.6 から入った SetConnMaxLifetime() で期限切れのコネクションを再利用しなくなった

Database sql from 明 高橋

www.slideshare.net

関連記事

既に参加者の記事が上がっていた！

kysnm.hatenablog.com

developers.cyberagent.co.jp

裏番組

mackerelio.connpass.com

実は裏番組で Mackerel Meetup #9 もあった．Mackerel 活用してるから参加したかったし，お世話になってる @ariarijp の LT も見たかったけど，golang.tokyo #3 を選んでしまった！たまたま抽選当たったから…w

カカカカックさんは #golangtokyo 組です

— songmu (@songmu) 2017年1月26日

ハッシュタグを見てたら「アノテーション機能」の話が流れてきて，あまりに待望の機能だったので，1人で興奮してた！

mackerel.io

次回の Mackerel Meetup は参加しまっす！

CloudWatch で ELB の「パーセンタイル統計」を可視化しよう

今日は CloudWatch の話を書こうと思う．既に活用してる人も多いと思うけど，2016年11月の新機能リリースで各種メトリクスの「パーセンタイル統計」を可視化できるようになった．

「パーセンタイル統計」は凄く重要で，平均値だけをモニタリングしていると気付きにくい異常値に気付くことができる．例えば，ELB の Latency をモニタリングしている場合に，リクエストの 1% が非常にパフォーマンスが悪いとしても，平均値で見ると値が丸まってしまって，通常より少し遅い程度にしか見えないという場合がある．そんなときに「パーセンタイル統計」を活用できる．

まだ全ての ELB に反映されていない

以下の記事を読むと，newly created ELB and ALB と書かれていて，新機能リリース以降に作成した ELB と ALB にしか対応していないように読み取れた．

• Amazon CloudWatch Update – Percentile Statistics and New Dashboard Widgets | AWS News Blog

Percentiles are supported for EC2, RDS, and Kinesis as well as for newly created Elastic Load Balancers and Application Load Balancers.

また別の記事を読むと，既に運用している ELB と ALB は will be available in the coming weeks であると書いてあった．ただし，数週間待っても反映されず，年を越してしまった．

• Elastic Load Balancing: Support for CloudWatch percentile metrics

Percentile metrics are available today for all new Application Load Balancers and can be accessed from the CloudWatch console, SDK and API. Support for existing Application Load Balancers and all Classic Load Balancers will be available in the coming weeks.

今週やっと ELB で「パーセンタイル統計」を可視化できるようになった

実は「パーセンタイル統計」が反映されたらすぐに気付けるように，以前から CloudWatch Dashboard にグラフを追加していたので，1/24 に「あ！反映された！」とすぐに気付くことができた（笑）

既に反映された ELB もあるし，まだ反映されてない ELB もある．リソースを作成した時期にもよりそう．

以下の例では，3種類の「パーセンタイル統計」を可視化している．特に p99 の値を見ると，異常値が検出できていることがわかる．

• Latency p99
• Latency p95
• Latency p90

グラフを作る Tips

ちなみに，グラフを作るときに「メトリクス追加」のようなボタンが無くて，どうやったら複数の「パーセンタイル統計」を表示できるのか全然わからなかった．適当にポチポチしてたら，右側にコピーアイコンがあることに気付いたけど，これは気付かないでしょう！ということで Tips も載せておく．

まとめ

既に「パーセンタイル統計」が反映されている ELB と ALB も多そうなので，CloudWatch Dashboard で可視化しておくと，異常値に気付くことができて便利！

最近は Grafana が最高すぎるから，CloudWatch のダッシュボードも Grafana に移行しようと思ってる．

kakakakakku.hatenablog.com

Tech Meetup に参加して「grafana-zabbix 活用術」を紹介してきた

今日は freee で開催された Tech Meetup に参加してきた．ダッシュボード厨としては最近導入した grafana-zabbix の紹介もしたいと思って「grafana-zabbix 活用術」というタイトルで LT もしてきた．懇親会でいろいろお話もできたし凄く楽しかった！

plaidtech.connpass.com

freee を支えるインフラ技術 @manabusakai

• Monyog - Monitor & optimize MySQL database performance は知らなかった！
• 「障害が起きることを前提に」は本当に重要
  • AWS Well-Architected Framework にも「コンポーネントの障害に対応するべし」と書かれてるし
  • 理解はしてるけど SPOF になってしまうこともあるよなぁ…と思ったり
• 「トラッキングして見える化」も重要だなと思った

speakerdeck.com

KARTE を支えるマルチプラットフォームインフラ監視 @ikemonn

• 「全員で壊しながら進む」
• AWS と GCP を使ってマルチプラットフォーム上に構築してる
• API Monitoring and Testing · Runscope API Testing & Monitoring なんてあるんだ
• ダッシュボードを障害のレイヤーごとに作る
  • ダッシュボード戦略として凄く参考になった！

speakerdeck.com

対談 @manabusakai & @ikemonn

• 会場は Zabbix ユーザーが非常に多かった
• 障害が起きたときにダッシュボードを作り直したりする
• アラートの閾値を決めるのはある意味職人芸と言える
• アラートは最初多めに出して段々と減らしていく

対談を聞きながら「そうそう！そうなんだよなー！」と思ってた．モニタリングと言っても，システムによって規模も違うし，ツールも違うし，負荷の特性も違って，非常に興味深く聞いていた．対談形式の発表は凄く良いなと思った．

prometheus 監視で変わるもの @sugitak

• 次世代監視の大本命！ Prometheus を実運用してみた - Qiita

speakerdeck.com

grafana-zabbix 活用術 @kakakakakku

会場に Zabbix ユーザーが多かったため，比較的興味を持ってもらえたような気がする．

特に grafana-zabbix は Zabbix Server に影響を与えずに導入できるため，使ってみて不要だったら消せば良いし，バージョンアップも簡単だし，運用の手軽さが良いなと思う．紹介した活用術は Grafana を使ってる人であれば既知の内容だったと思うけど，Grafana は最初「どう使うんだろう？」と悩むことがあるし，機能も多いため，今後使う人の参考になれば良いなと思っている．最高のダッシュボードを作ろう！

あと「モニタリングは “Proactive” と “Reactive” に分類される」と紹介した Effective Monitoring and Alerting も是非読んでみると良いかと！

Effective Monitoring and Alerting: For Web Operations

grafana-zabbix はコチラから！

github.com

speakerdeck.com

プロセス生存確認サービス始めました @narita-takeru

• NurseCall
• プロセス監視専用のサービスを作った
• コマンドは Golang 製 / 管理画面は Rails 製

関連記事

発表冒頭に紹介した CyberAgent Developers Blog に僕が書いた記事も是非合わせて見て頂けると！

developers.cyberagent.co.jp

AWS Well-Architected Framework に5本目の柱 "Operational Excellence" が追加されていた

AWS を運用しているエンジニアなら読んだ人も多いであろう，2015年10月に公開された "AWS Well-Architected Framework" に実は大幅なアップデートが入っていることに気付いた．時期的には AWS re:Invent 2016 の直前で，AWS re:Invent 2016 で発表された新サービスを見越していたんだろうと推測できる．

• Are You Well-Architected? | AWS Blog
• AWS Well-Architected Framework

アップデート内容としては大きく2個ある．

• 今までの4本の柱のベストプラクティスが一部見直された
• 新たに5本目の柱 "Operational Excellence" が追加された

今回アップデートされた "AWS Well-Architected Framework" を理解するために活用した「AWS Well-Architected 研修」を紹介しつつ，実際に "Operational Excellence" を読んでみた感想をまとめておこうと思う．

無料で受講できる「AWS Well-Architected 研修」

以下のページにある "Training" からリンクを辿ると「AWS Well-Architected 研修」を受講することができる．しかも無料．ちゃんと "Operational Excellence" も含まれていて，最新版の "AWS Well-Architected Framework" に準拠した内容になっていた．

aws.amazon.com

カリキュラム

カリキュラムは6個あり，"AWS Well-Architected Framework" の全体概要を学ぶカリキュラムと，柱ごとの概要を学ぶカリキュラムがある．

• AWS Well-Architected - Module 1: The AWS Well-Architected Framework
• AWS Well-Architected - Module 2: The Security Pillar
• AWS Well-Architected - Module 3: The Reliability Pillar
• AWS Well-Architected - Module 4: The Performance Efficiency Pillar
• AWS Well-Architected - Module 5: The Cost Optimization Pillar
• AWS Well-Architected - Module 6: The Operational Excellence Pillar

全体的に良いなと感じたのは以下の3点だった．AWS 初学者にもオススメできる．

• 動画内に Knowledge Check があって理解度確認をしながら進められること
• 関連資料のリンクも多く紹介されていること
• オンプレ環境など従来の環境とクラウドネイティブな環境の比較を学べること

学んだこと

• "一般的な設計の原則" に "Improve through game days" が新たに追加されていた
  • 本番環境と同等なリクエストでアーキテクチャをテストすることによって改善に役立てるべき（これを "Game Days" と表現している）
  • "Game Day" は AWS 主催のトラブルシューティングコンテストのようなもの（ISUCON 的な）
• "パフォーマンス効率の柱" に "Mechanical sympathy" が新たに追加されていた
  • 処理特性などを考えて，達成したいことに最適な技術を選択するべきということ
• "コストの最適化の柱" の Key AWS Services（最も重要なサービスのこと）が "コスト配分タグ" だった
  • 知らなかった...

認定証

"Operational Excellence" を読んでみた

まだ日本語訳になった資料は公開されていないが，"Operational Excellence" は "運用上の優秀性" と訳されていた．"Operational Excellence" をザッと読んでみた．あくまで個人的なコメントなので，是非実際に PDF を読んで頂きたい！

設計の原則

• Perform operations with code
  • インフラ運用をコード化しよう！
• Align operations processes to business objectives
  • ビジネス目標に合わせた運用プロセスにしよう！
• Make regular, small, incremental changes
  • 定期的に／小さく／段階的に変更しよう！サービスのダウンタイムを取らないように運用手順を考えよう！
• Test for responses to unexpected events
  • 障害など予期しないイベントに備えてテストしよう！
• Learn from operational events and failures
  • 失敗から学んで運用をさらに良くしよう！
• Keep operations procedures current
  • 運用手順書や障害対応手順書を更新し続けよう！

ベストプラクティス（質問集）

OPS 1. What best practices for cloud operations are you using?

• Operational Checklist
• Proactive Plan
• Security Checklist

チェックリストを作って確認できるプロセスにすることは確かに重要だなと思った．2013年から更新されていない点は気になるけど，AWS から公式に "Operational Checklists for AWS" が公開されていて，"AWS Well-Architected Framework" と似たような観点で確認するべきチェックリストが用意されている．

• Operational Checklists for AWS

またビジネス的にインパクトのあるキャンペーンを実施するときなどは事前に計画して運用時に考慮するべきと書かれている．僕が担当してるシステムだと，テレビ砲や Yahoo! 砲が予定されているときは事前に共有をもらうようにしている．

OPS 2. How are you doing configuration management for your workload?

• Resource Tracking
• Documentation
• Capture Operational Learnings
• Immutable Infrastructure
• Automated Change Procedures
• Configuration Management Database (CMDB)

一言で言うと Infrastructure as Code を目指そうという内容だった．ドキュメント化（コード化）して，GitHub などで管理して，反映も自動化することが重要と書かれている．

OPS 3. How are you evolving your workload while minimizing the impact of change?

• Deployment Pipeline
• Release Management Process
• Small Incremental Changes
• Revertible Changes
• Risk Mitigation Strategies

リリースの影響を小さくするために，デプロイフロー（継続的インテグレーション／継続的デリバリー）を整えたり，リリース戦略（Blue/Green デプロイメント／カナリアリリース／AB テスト）を適用したりするべきと書かれていた．特に "Revertible Changes" は実現できていないところもあって考えてみたい．ロールバックだけではなく，フィーチャートグルにも言及されていたのは良かった．

OPS 4. How do you monitor your workload to ensure it is operating as expected?

• Monitoring
• Aggregate Logs
• Alarm-Based Notifications
• Trigger-Based Actions

内部的な要因や外部的な要因で障害は発生してしまうため，適切にモニタリングして，異常値であればアラートを飛ばしたり，自動的にアクションを実施したりするべきと書かれていた．

OPS 5. How do you respond to unplanned operational events?

• Playbook
• RCA Process
• Automated Response

障害が発生したときにどのように対応するかという話だった．Playbook の適切な日本語訳がわからないけど，オンコールプロセスを用意したり，障害の影響度に応じて組織内でエスカレーションしていくプロセスを決めておくなどが例として挙がっていた．"Automated Response" も今後は考えたい．自動化できる対応は自動化して運用を楽にするべき．

OPS 6. How is escalation managed when responding to unplanned operational events?

• Appropriately Document and Provision
• Functional Escalation with Queue-based Approach
• Hierarchical Escalation
• External Escalation Path
• Hierarchical Priority Escalation is Automated

OPS 5. と関連していて，エスカレーションをどのように管理するかという話だった．組織内でエスカレーションしていくプロセスを決めておくだけではなく，AWS サポートや外部サービスのサポートなど，影響する可能性のあるパートナーのエスカレーションパスも事前に用意しておくという話は参考になった．

Achieving Agility by Following Well-Architected Framework Principles (ARC203)

AWS re:Invent 2016 で "AWS Well-Architected Framework" に関するセッションがあった．

www.youtube.com

まとめ

• 2016年11月に "AWS Well-Architected Framework" が大幅にアップデートされていた
• 無料で受けられる「AWS Well-Architected 研修」があった
• 5本目の柱 "Operational Excellence" を読むと，システムを安定稼働させるためのベストプラクティスと，障害時に迅速に対応するためのベストプラクティスが学べた

関連記事

kakakakakku.hatenablog.com

CircleCI + ShellCheck でシェルスクリプトを静的解析する

シェルスクリプトのレビューを効率化するため，シェルスクリプト専用の静的解析ツール "ShellCheck" を導入して，さらに CircleCI で自動テストすることにした．導入検証も兼ねて，個人的に使ってる dotfiles に導入してみた話をまとめる．

github.com

apt-get install shellcheck はできなかった

CircleCI で稼働するコンテナは "Ubuntu 12.04 (Precise)" or "Ubuntu 14.04 (Trusty)" なので，README に書いてある通り apt-get install shellcheck を circle.yml に書いて実行したら，エラーになってしまった．apt-get update も効果は無かった．

$ sudo apt-get install shellcheck
Reading package lists... Done


Building dependency tree       


Reading state information... Done

E: Unable to locate package shellcheck

sudo apt-get install shellcheck returned exit code 100

Action failed: sudo apt-get install shellcheck

Issue を確認したら「Cabal を試してみて！」や「Ubuntu 用にパッケージングするのは良いけど，手伝ってくれる人はいる？」といったコメントがポストされていたけど，その後の進展は無くて，現時点だと難しそうだな...と判断した．

github.com

github.com

Cabal を使って ShellCheck をインストールした

よって，Cabal を使うことにした．CircleCI だとデフォルトで Cabal がインストールされていて，特に意識する必要は無かった．

circleci.com

しかし，Cabal 経由で ShellCheck でインストールすると，遅すぎる問題があった．以下のログを見るとわかる通り，8分も実行したままになってしまう...！回避策としては ~/.cabal を cache_directories に設定して，コンテナ起動時にリストアできるようにし，既にインストールされている場合はスキップするようにした．

ドキュメントを見ると Cabal はデフォルトで cache_directories の対象になっているようにも読み取れるけど，今回は明示的に書くことにした．

circleci.com

完成した circle.yml

machine:
  environment:
    PATH: ${HOME}/.cabal/bin/:${PATH}

dependencies:
  cache_directories:
    - "~/.cabal"
  post:
    - cabal --version
    - cabal update
    - if ! type shellcheck > /dev/null; then cabal install ShellCheck; fi
    - shellcheck --version

test:
  override:
    - shellcheck --exclude=SC2039 *.sh

github.com

静的解析エラーを検出できるようになった

（shellcheck にパスを通す前に動かしたキャプチャだから絶対パスになっている）

CircleCI Feature Requests

ShellCheck をデフォルトで使えるようにして！とリクエストは出ていた．

discuss.circleci.com

まとめ

• シェルスクリプトだって CI で静的解析エラーを検知したい
• ShellCheck 便利（ルールが厳しすぎるけど...w）
• CircleCI で動かす場合は Cabal 経由でインストールすると良い（cache_directories も必ず使うこと）