kakakakakku blog

Weekly Tech Blog: Keep on Learning!

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

AWS

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

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

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

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

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 であると書いてあった．ただし，数週間待っても反映されず，年を越してしまった．

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

f:id:kakku22:20170127194516j:plain

グラフを作る Tips

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

f:id:kakku22:20170127195918j:plain

まとめ

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

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

kakakakakku.hatenablog.com

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

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

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

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

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

アップデート内容としては大きく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（最も重要なサービスのこと）が "コスト配分タグ" だった
    • 知らなかった...

認定証

f:id:kakku22:20170110020944p:plain

"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" と似たような観点で確認するべきチェックリストが用意されている．

またビジネス的にインパクトのあるキャンペーンを実施するときなどは事前に計画して運用時に考慮するべきと書かれている．僕が担当してるシステムだと，テレビ砲や 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 でシェルスクリプトを静的解析する

CircleCI Shell

シェルスクリプトのレビューを効率化するため，シェルスクリプト専用の静的解析ツール "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

f:id:kakku22:20170105003602p:plain

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

f:id:kakku22:20170105003858p:plain

ドキュメントを見ると 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 にパスを通す前に動かしたキャプチャだから絶対パスになっている）

f:id:kakku22:20170105170240p:plain

CircleCI Feature Requests

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

discuss.circleci.com

まとめ

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

2016年の振り返りと2017年の抱負

日記

2016年の振り返り

実戦投入力を高めることができた

2016年の抱負として掲げた「実戦投入力を高める」という目標を大きく達成することができた1年だった．「実戦投入力」とは「プログラミング言語，ミドルウェア，オープンソースなどをサービスに投入して実践的に使うこと」と定義している．日々「○○を試した」系のブログ記事を書いているが，実際にサービスに投入するためには運用面も考える必要があるし，チームに普及させる必要があるし，メリットがあることを組織に理解してもらう必要がある．またデメリットも予め考えておく必要がある．そういった「ラストマイル」的な部分も含めて経験することによって，スキルレベルが深まるし，社外発表のネタにもなると考えていて，1年間ずっと意識してきた．

1年前と比べると，圧倒的に AWS に詳しくなったし，ミドルウェアの運用面にも詳しくなったし，モニタリング技術にも詳しくなった．ずっと憧れていたウェブオペレーションエンジニアとして働くことができて本当に良かった（正確に言うと2016年3月頃からメインでウェブオペレーションを担当している）．総じて「実戦投入力を高める」という目標設定が良かったなと感じている．

大きく成果を出すことができた

「実戦投入力を高める」という目標は個人のスキルアップだけではなく，組織にも大きく影響を与えることができた．サービスの大きな課題になっていたウェブオペレーションの部分を改善し安定性とスケーラビリティを格段に上げることができたし，チームメンバーのモチベーションアップにも大きく貢献したという話も聞いた．また評価もして頂くことができて，昇進をしたり，社内表彰に何度も名前が挙がったりもした．個人的に「頑張ったら評価される」とは思っていなくて「着実に成果を出し続けて，貢献度を組織（特に経営層）にアピールする」ことを常に意識していた結果だと思う．

さらにもう1点重要だったと思うことがある．それは「愚痴らない」と決めたことだった．2015年は比較的荒れていた時期も多く，Twitter に弱音を吐いたり，友人に愚痴っていたこともあった．今年は愚痴りたくなったら「その課題を解決するにはどうしたら良いんだろう？」を考えることを徹底した．その結果として，課題が明確になったし，考えた結果，課題ではなかったと気付けたこともあったし，何よりも「次のアクションに繋がる」ことが重要だった．これもまた成果に繋がった理由の一つだなと確信している．

たくさんアウトプットした

発表（社外）

2015年と同じく計4回社外発表をした．特に10月に発表した Coursera の体験談は非常に反応が良くて，発表後の懇親会でも話が盛り上がったし，凄く楽しかった．今年は LT だけじゃなく，ロングトーク枠で発表することを目標にしたい．

発表（社内）

2015年と同じく計7回社内発表をした．社内勉強会でも本気で準備をしていて，今年は「監視入門」や「Exponential Backoff」など，ホッテントリに入った記事も多くて嬉しかった．社内勉強会の運営は引き続き担当しているので，運営ノウハウを共有する「メタ勉強会」がまた開催されたら是非参加したい．

プルリクエスト

別記事にまとめた．2017年も積極的にコントリビュートしていくぞ！

ブログ

計125回更新できた．基本的に「週2回更新」をノルマにしていて，定期的にアウトプットすることが習慣になっているのは自分でも良いことだなと思う．ただし，2017年は新たな目標のために時間捻出が重要になるため，「週1回更新」をノルマにして，余力があったら「週2回更新」にしようと思っている．

たくさんインプットした

勉強会に参加した

今年は秋頃など意図的に勉強会の参加を控えた時期もあったけど，それでも多く参加することができた．今年は技術領域もある程度絞って「Golang / AWS / Docker / 監視モニタリング」関連にフォーカスして参加していた．

Coursera を受講して修了した

「アカデミックに基礎技術を学び直したい」という強い気持ちがあった．最初は MBA（経営システム科学専攻）を取得することも候補として考えていたけど，スパンが長くなってしまうし，仕事と並行してできることを考えた結果 MOOC だな！となった．今年は Coursera で “Cloud Computing Concepts, Part 1” を受講して「分散システム論」を学ぶことができた．5週間大変だったけど，毎日楽しすぎて，ナチュラルハイな状態が続いていた．今年も絶対また受講しようと思う．詳しくは以下の記事にまとめた．

2017年の抱負

（継続）実戦投入力を高める

去年と同じく「実戦投入力を高める」ことを目標にする．去年は「技術的負債の解消」を中心に実戦投入することが多かったが，今年は「攻めるインフラ」のために実戦投入をしていきたい．やりたいことが無限にある．今の自分に満足すること無く，常に成長し続ける．

技術支援を仕事にする

今年は新たに「技術支援を仕事にする」ことを目標にアクションを積み上げていく．年末に「本当に挑戦したいこと」を発見するためにマインドマップを書いて，自分の目指している方向性に気付くことができた．自分は「技術者のためにパーソナライズしたアウトプットがしたい」ということだった．まだ「技術支援」の明確なイメージまで決められて無くて，候補としては「プログラミング指導／クラウド導入支援／ソリューションアーキテクト／サポートエンジニア／技術顧問」などを検討しているが，あまり背伸びせずに，今の自分の市場価値を考慮した上で判断したい．

英語でコミュニケーションを取れるようにする

今まで read / write を中心に使ってきた英語を speak / listening にまで幅を広げて，英語で苦労することなくコミュニケーションを取れるように学んでいきたいと考えている．具体的に言えば，海外のエンジニアとディスカッションをできるようになったり，海外イベントに登壇できるようになったりすることを想定している．まずは「英会話」を習って日常的に英語を使う機会を増やしていく．

まとめ

今年もよろしくお願いします 🙇

過去の振り返り