shiimaxx

レビューに参加した「達人が教えるWebパフォーマンスチューニング」をご恵贈いただきました。ありがとうございます！感想本書では、Webサービスを高速化するための基礎知識や考え方、そして具体的な計測と改善の手法についてISUCONを題材にして解説しています。ボトルネック）を特定して改善することが重要であること、最も遅い箇所（ボトルネック）を特定する方法、Webサーバ・アプリケーション・データベース・OSといった各レイヤにおける高速化の手法を学ぶことができます。学んだ知識をISUCONの環境を使って実際に手を動かして試せるというのは重要なポイントだと思います。Webサービスのパフォーマンス問題に立ち向かう際に大いに役立ちました。付録Bのベンチマーカの実装はISUCON勢として興味深く読ませていただきました。なかでも実装パターンの解説については、ISUCONのベンチマーカを実装したい人だけでなくGoを書く人にとっても参考になると思います。

「達人が教えるWebパフォーマンスチューニング」を読んだ

2021/12/01に株式会社Topotalに入社していました。本日12/1 株式会社 Topotal に入社しました。SRE as a Service を提供するエンジニアとして、お客様の SRE の実践をお手伝いしていきます！https://t.co/ITfMDu0eSN— Takatada Yoshima (@shiimaxx) 2021年12月1日  自分はフルタイムでSRE as a ServiceというSite Reliability Engineering(以降SRE)を軸にした技術支援サービスの提供をしています。入社半年という区切りのよい時期なので、半年間で取り組んだことをまとめてみました。やったこと前提として2〜3社のお客様の支援を同時並行で行っています。他にも細々したものはありますが主にこんな感じです。Terraform AWS ProviderのアップデートDatadogでgRPCエンドポイントのモニタリングコンテナレジストリ間でイメージ同期する仕組み作りGKEクラスタの可用性向上モニタリングの整備Infrastructure as codeの導入SLO導入お客様によってインフラ/SRE組織のフェーズは様々なので、お手伝いする内容も幅広くなっています。ラクティスを導入するだけではなく、組織にあわせてどのように運用できるかを一緒に考えたり、お客様の社内でのSREの理解促進のために各種取り組みのモチベーションを説明するドキュメントを書くということもしました。SREの実践の支援においては、自分自身がSRE自体に対する一定の理解はあるものの、実際に組織に導入するということはやったことがなかったため、社内のメンバーから知見をもらったり、日々SRE book、SRE Workbook、Seeking SRE、各種事例やドキュメントなどを参照して理解を深めつつ、お客様の組織における実践に適用していくということをやっていました。技術トピックとしては、AWS全般、GCP（GKE、Cloud Run）、Terraformあたりを触ることが多かったです。OSSとして公開しているものもあります。プログラミング言語の指定があったことはなく、その時々で用途や好みで選定していました。自分の場合はGo、Ruby、Pythonのどれかにしていました。宣伝TopotalではSREを積極採用しています。ご興味のある方は問い合わせ・申込みをしていただけると嬉しいです！https://topotal.com/careers/software_engineer_sre

株式会社Topotalに入社して半年経ちました

去年に引き続き、今年も @nari_ex、@kur_neko、@shiimaxx の3人で「( (0) / (0)) ☆祝☆」というチームで参加しました。結果は予選敗退、当日のベストスコアは35902でした。当日やったこと利用言語はGoです。予選当日マニュアル、アプリケーションマニュアルをしっかり読むボトルネック調査アクセスログ解析: kataribeスロークエリログ解析: pt-query-digestシステムリソース: top, dstatアプリケーション: pprof, fgprofインデックス追加ALTER TABLE isu_condition ADD INDEX idx_jia_isu_uuid_timestamp (jia_isu_uuid, timestamp);自動prepared statementを抑制するためにDSNにinterpolateParams=trueを追加トランザクション内でやる必要のない処理を外出しGET /api/trendISUの性格は固定だったのでアプリケーション内部でsliceとして持たせてDB参照しない不要なカラムは取得しないアプリケーション内で0.8秒キャッシュMariaDBをMySQL 8.0に変更サーバ構成変更isucondition-1Nginx, Application(Go)isucondition-2MySQL(isu_conditionのみ)isucondition-3MySQL(isu_condition以外)この他にDBに入っている画像の外出しやGET /api/trendのN+1対策をしていましたが、どちらも実装しきれず諦めています。延長戦後日実施した反省会で、スコアを上げるための要点が正確に把握できておらず注力する箇所を間違っていた、そもそも実装スピードが足りない、という課題があがりました。解法を知らない状態でやりたかったので、予選関連エントリはほぼ読まず(1〜2エントリだけ軽く目を通した)、予選講評は読まない状態でやりました。環境MacBook Pro (13-inch, 2017) 上にVagrantで以下の環境を起動しました。matsuu/vagrant-isucon/isucon11-qualifier-standaloneCPU 2コア、メモリ 2GBベンチマーカ相乗りスコア予選突破ラインのスコアは、チーム「俺達の戦いはこれまでだ」の106094なので、このスコア以上を目標にします。本番はAmazon EC2のインスタンスを3台利用できるので構成の差異がありますが、縛りプレイということにして上記の環境で予選突破ラインのスコアを目指すことにしました。初期スコアは1242。当日やったこと（構成変更以外）を適用した後のスコアは18019でした。〜 35000POST /api/condition/<uuid> のINSERTをbulk insertにする → 20534予選関連エントリでチラ見してしまった内容なのですが、リクエストに含まれるISUのコンディションを都度INSERTしている箇所をbulk insertに変更しました。sqlxのNamedExecを利用して以下のように実装。   var values []map[string]interface{}    for _, cond := range req {        timestamp := time.Unix(cond.Timestamp, 0)        if !isValidConditionFormat(cond.Condition) {            return c.String(http.StatusBadRequest, "bad request body")        }        values = append(values, map[string]interface{}{            "jia_isu_uuid": jiaIsuUUID,            "timestamp":    timestamp,            "is_sitting":   cond.IsSitting,            "condition":    cond.Condition,            "message":      cond.Message,        })    }    _, err = tx.NamedExec(        "INSERT INTO `isu_condition`"+            "    (`jia_isu_uuid`, `timestamp`, `is_sitting`, `condition`, `message`)"+            "    VALUES (:jia_isu_uuid, :timestamp, :is_sitting, :condition, :message)", values,    )    if err != nil {        c.Logger().Errorf("db error: %v", err)        return c.NoContent(http.StatusInternalServerError)    }iconをDBから外出し → 21813当日に@kur_nekoが8割方実装してくれていたのを再利用して実装しました。最新のISUのコンディションをキャッシュしてGET /api/getTrend、GET /api/isuのDB参照を減らす → 23686initializeで以下の処理を実行してキャッシュを準備、POST /api/condition/:jia_isu_uuidでコンディションを受けっ取ったときにも都度最新データを更新するようにして、最新のISUのコンディションを参照する箇所ではこのキャッシュを利用するようにしました。var latestIsuConditions sync.Mapfunc prepareLatestIsuCondition() error {    rowsx, err := db.Queryx("SELECT `isu_condition`.* FROM (SELECT `jia_isu_uuid`, MAX(`timestamp`) `latest_timestamp` FROM `isu_condition` GROUP BY `jia_isu_uuid`) `tmp`, `isu_condition` WHERE `tmp`.`jia_isu_uuid` = `isu_condition`.`jia_isu_uuid` AND `tmp`.`latest_timestamp` = `isu_condition`.`timestamp`")    if err != nil {        return err    }    for rowsx.Next() {        var condition IsuCondition        err = rowsx.StructScan(&condition)        if err != nil {            return err        }        latestIsuConditions.Store(condition.JIAIsuUUID, condition)    }    return nil}GET /api/condition/:jia_isu_uuid の改善 →27362isu_conditionテーブルにis_dirty、is_overweight、is_brokenカラムを追加して必要なコンディションのレコードのみ取得できるようにしたり、必要な件数分のレコードのみを取得するようにLIMITを追加したりしました。dropProbability := 0.8、コネクションプールの接続数を100 →34398試しにやってみたらスコアが結構上がりました。これまでの変更が効いたプチブレイクスルーと思われます。〜85000GET /api/isu/:jia_isu_uuid/graph の改善 → 41850isu_conditionテーブルから指定されたjia_isu_uuidの全レコードを引っ張っていたが、コードを読んでみると1日分のデータしか利用していないようだったので、timestampカラムで条件を絞ってDBからのデータ取得の件数を絞りました。あと、calculateGraphDataPointの処理はWINDOW関数というやつでできるのでは、と思い頑張ってSQLを作って実装。が、この時点ではスコアにはあまり効果がありませんでした。インデックスを上手く使わせられず、EXPLAINして実行計画を見てみるとUsing temporary; Using filesortが出ていたので単にアプリケーションの負荷がMySQLに移っただけで全体としての効果が薄かったのかもしれません。   query := "SELECT\n" +        "       `isu_condition`.*,\n" +        "       DATE_FORMAT(`timestamp`, '%Y-%m-%d %H:00:00') `truncate_timestamp`,\n" +        "       SUM((\n" +        "         CASE WHEN `condition_level` >= 3 THEN 1\n" +        "         WHEN `condition_level` >= 1 THEN 2\n" +        "         ELSE 3 END\n" +        "       )) OVER w * 100 / 3 / COUNT(*) OVER w `score`,\n" +        "       AVG(`is_sitting`) OVER w * 100 `sitting_percentage`,\n" +        "       AVG(`is_broken`) OVER w * 100 `is_broken_percentage`,\n" +        "       AVG(`is_overweight`) OVER w * 100 `is_overweight_percentage`,\n" +        "       AVG(`is_dirty`) OVER w * 100 `is_dirty_percentage`\n" +        "     FROM `isu_condition`\n" +        "     WHERE `jia_isu_uuid` = ?\n" +        "       AND `timestamp` >= ? AND `timestamp` < ?\n" +        "     WINDOW w AS (PARTITION BY `truncate_timestamp`)\n" +        "     ORDER BY `timestamp` ASC"いくつかトランザクションを削除 → 49274pt-query-digestのスロークエリログ解析の結果から、ロック待ちで時間がかかっているクエリが多かったので改めて見直したところ、必要のないトランザクションがいくつかあったので削除しました。トランザクションについてはこの後も何度か見直していて、異常系を考慮しなければなくてもよいものと読み取れたので最終的には全廃しました。dropProbability := 0.7 → 51876細かい変更を色々→ 84391JIAServiceURLはDBではなくグローバル変数に保存するisu_conditionからAUTO_INCREMENTなidカラムを削除してプライマリキーをjia_isu_uuidとtimestampの複合キーに変更loglevelをDEBUGからERRORに変更dropProbability := 0.6作成済みのISUのリストをキャッシュして、以下のようなISUの存在チェックのためのクエリを削減var count interr = db.Get(&count, "SELECT COUNT(*) FROM `isu` WHERE `jia_isu_uuid` = ?", jiaIsuUUID)〜10000overPOST /api/condition/:jia_isu_uuid で受け取ったコンディションをキューイングして単一のGoroutineでbulk insert → 96413このあたりで若干手詰まり感。POST /api/condition/:jia_isu_uuidのスループットを上げる必要があるんだろうな、とは考えていたものの手段が思いつかず。そこで、改めて予選当日マニュアルを読んでみたところ、POST /api/condition/:jia_isu_uuid で受け取ったコンディションの反映が遅れることをベンチマーカーは許容しています。という記載が目につき、POST /api/condition/:jia_isu_uuidのレスポンスを返す時点でコンディションが反映されていなくてよいのであれば、一旦キューイングして一定間隔でまとめてINSERTするようにすれば競合せずにスループットが上がるのでは、と考えて実装してみました。POST /api/condition/:jia_isu_uuidの中からは送られてきたコンディションをchannelで送信するだけにして、実際にDBにINSERTする処理はgoroutineで動かしている以下の関数内でやります。func updateIsuCondition(q chan map[string]interface{}) {    var records []map[string]interface{}    for {    wait:        for {            select {            case record := <-q:                records = append(records, record)            case <-time.After(10 * time.Millisecond):                break wait            }        }        if len(records) > 0 {            _, err := db.NamedExec(                "INSERT INTO `isu_condition`"+                    "    (`jia_isu_uuid`, `timestamp`, `is_sitting`, `condition`, `message`, `is_dirty`, `is_overweight`, `is_broken`)"+                    "    VALUES (:jia_isu_uuid, :timestamp, :is_sitting, :condition, :message, :is_dirty, :is_overweight, :is_broken)", records,            )            if err != nil {                fmt.Println(err)            }            records = []map[string]interface{}{}        }    }}これが効いて一気にスコアが10k以上アップ。システムリソースに余裕がある状態だったので、更にdropProbabilityを調整していきます。dropProbability := 0.4 → 116797dropProbabilityを0.5→0.4→0.3と調整してみたところ、0.4で最高スコアが出ました。目標であった106094を超えるスコアも達成。03:54:51.191862 score: 116797(116828 - 31) : pass03:54:51.191882 deduction: 31 / timeout: 003:54:51.191889 <=== sendResult finishまとめ予選の翌日から2週間、少しず進めてある程度のスコアを出すことができました。実装の練習になりますし、どのようにスコアが積み上がっていくのかというのを体験できてよかったと思います。ISUCON11 予選問題の解説と講評を読んでみました。実施した内容が想定解法から大きくハズレていないという点についてはよかったのですが、そこに辿り着くまでに結構遠回りをしてしまっていたので、引き続き計測結果から正確にボトルネックを読み取れるようになるという課題に向き合う必要があるかなと思っています。ISUCONでは8時間で成果を出す必要がありますし。最後に、運営の皆様今年もISUCONを開催していただきありがとうございます！予選本番だけでなく、事前練習や延長戦も含めて長く楽しませていただいています。本選問題が公開されたらそちらにもチャレンジしてみようと思います。

ISUCON11で予選敗退して悔しかったので予選突破ラインのスコアが出るまで延長戦をやりました

ISUCON10の予選にnari_exさん、kur_nekoさんと「( (0) / (0)) ☆祝☆」というチームで参加しました。最終スコアは1422でした。事前準備個人練習でISUCON8、ISUCON9の予選問題をGoで解きました。いずれも予選突破ラインのスコアが出るまでチューニングし、その過程で以下のことの練習や確認ができたと思います。レギュレーション、マニュアル、アプリケーション仕様書から問題のポイントをつかむGoでのオンメモリキャッシュや並行処理の書き方sqlxやgo-redisなどのライブラリの利用方法kataribeやpprofなどの解析ツールの利用方法と解析結果の見方MySQLのロックの挙動についてまた、予選の前々日にZoomで打ち合わせをしました。昨年の反省を振り返りつつ、レギュレーションの読み合わせや役割分担を行いました。当日それぞれ自宅からリモートで参加しました。Zoomを常時接続しておいて、テキストでの情報共有はSlack、Scrapboxを使いわけて行いました。序盤昨年の反省から、まずはサービスの背景やアプリケーションについてしっかり理解してから手を動かそうと話していたので、nari_exさんとわたしでマニュアルを読む、サービスを使ってみる、ということをやって、それぞれScrapboxに情報をまとめていきました。ミドルウェア解析用のログ出力設定などの下回りの整備をやってもらいました。初回ベンチマークを実行して初期スコアは500ちょっと。ベンチマーク実行中にtopコマンドの出力を眺めていたらMySQLのCPU使用率が支配的だったので、まずはインデックス追加やクエリの改善・削減をやっていく方針になりました。今回スコアに直結するエンドポイントは、POST /api/chair/buy/:idとPOST /api/estate/req_doc/:id で、そこへの導線になるであろう検索が重要そう、というのがマニュアルを読んだうえでの理解。kataribeでアクセスログ解析を行った結果を見ても検索まわりのURLのリクエスト回数やレスポンスタイムが多かったので、そのあたりを中心に見ていきました。やったことは次のとおり。インデックス追加GET /api/recommended_estate/:id のクエリの修正イスがドアに入るかどうかはイスの短辺だけでチェックすればOKMySQL 8.0化ORDER BY popularity DESCの部分で降順インデックスを使うために採用スコアが下がってしまったのでパラメータチューニングを実施アップデート前よりスコアは下がってしまったが今後の伸びしろに期待してとりあえずそのまま利用継続中盤検索APIのクエリでrent、doorHeight、doorWidthなどの条件が範囲検索になっていてインデックスうまく使えていなかったので、それぞれ値に対応したrangeIdを保存するカラムを追加してそれを利用するように変更。このあたりから/initializeの初期化処理が30秒以内に完了せずベンチマーク実行がFailするようになりました。タセットを別テーブル（estate_customize、chair_customize）にもっておいて、初期化処理をCREATE TABLE estate LIKE estate_customize;INSERT INTO estate SELECT * FROM estate_customize;でデータをコピーする方式に変更。作業に手間取って1時間くらい消費してしまったのがもったいなかった。あとはBotからのアクセスが目立ってきたので、NginxでBotからのアクセスに503を返すようにしました。終盤この時点での最高スコアは1200ちょっと。予選突破ラインは2000くらいかなと予想していたのですが、残り時間も少なかったので大幅な改修には着手できず。MySQL5.7→MySQL 8.0でスコアが下がってしまった分をバージョン差し戻しで取り戻せないかな、ということで差し戻してみたのですが効果がなかったのでやめ。SELECT COUNT(*)のクエリが相対して多くなっていたので、必要なインデックスをひたすら追加するなどして、最終スコア1422でFinishしました。まとめ予選突破ラインのスコアを出すためには施策をもう3、4手打つ必要があったと思っていて、それができなかったのは実力不足だったと思っています。予選問題のゲーム性の理解やチームの役割分担は例年よりうまく行った感があったので、さらに上積みしつつ来年もチャレンジしたいです。運営の皆様、今年も楽しい問題をありがとうございました。予選突破された皆さんは本選でも頑張ってください。

ISUCON10予選に参加しました

GitHubにホストしているプロジェクトでは、Changelog生成にghchを、Releaseの作成にはghrを利用しているのですが、同じようなことをGitLabにホストしているプロジェクトでもやりたかったので作りました。どちらもGo実装です。glchhttps://github.com/shiimaxx/glchGitのタグとGitLabのMerge RequestからChangelogを生成します。ghchがGItのタグとGitHubのPull RequestからChangelogを生成するのでその挙動を参考にしました。$ glch## v0.2.0 - 2020-05-09- Feature 2 shiimaxx/glch-demo!2 from [@shiimaxx](https://gitlab.com/shiimaxx)- Feature 1 shiimaxx/glch-demo!1 from [@shiimaxx](https://gitlab.com/shiimaxx)## v0.1.0 - 2020-05-09- Initial release最新のタグ以降に更新がある場合は、デフォルトだとUnreleasedセクションに出力します。$ glch## Unreleased - 2020-05-09- Feature 3 shiimaxx/glch-demo!3 from [@shiimaxx](https://gitlab.com/shiimaxx)## v0.2.0 - 2020-05-09- Feature 2 shiimaxx/glch-demo!2 from [@shiimaxx](https://gitlab.com/shiimaxx)- Feature 1 shiimaxx/glch-demo!1 from [@shiimaxx](https://gitlab.com/shiimaxx)## v0.1.0 - 2020-05-09- Initial release-next-versionオプションを使うとUnreleasedの代わりにバージョンを指定できます。$ glch -next-version v0.3.0## v0.3.0 - 2020-05-09- Feature 3 shiimaxx/glch-demo!3 from [@shiimaxx](https://gitlab.com/shiimaxx)## v0.2.0 - 2020-05-09- Feature 2 shiimaxx/glch-demo!2 from [@shiimaxx](https://gitlab.com/shiimaxx)- Feature 1 shiimaxx/glch-demo!1 from [@shiimaxx](https://gitlab.com/shiimaxx)## v0.1.0 - 2020-05-09- Initial release出力するChangelogのフォーマットは、keep a changelogを参考にしたものにしています。glrhttps://github.com/shiimaxx/glrGitLabのReleaseを作成するCLIツールです。-uploadオプションでファイルもしくはディレクトリを指定するとReleaseの作成とともにファイルをアップロードできます。$ glr -upload ./dist v0.1.0[Created release]Title: v0.1.0Release assets:--> glr_v0.1.0_darwin_amd64.zip: https://gitlab.com/shiimaxx/glr-demo/uploads/.../glr_v0.1.0_darwin_amd64.zip--> glr_v0.1.0_linux_amd64.tar.gz: https://gitlab.com/shiimaxx/glr-demo/uploads/.../glr_v0.1.0_linux_amd64.tar.gzアップロードしたファイルはRelease assetsになります。ローカルのファイルをアップロードする方法とは別に、-asset-nameオプションと-asset-urlオプションを利用して任意の名前とURLでRelease assetsを作成する方法も用意しています。これによりGitLab CI/CDのBuild artifactsやS3などに置いたファイルをRelease assetsにできます。参考https://github.com/Songmu/ghchhttps://github.com/tcnksm/ghrkeep a changelog

GitLabのMergeRequestからChangelogを生成するglchとGitLab Releaseを作成するglr

Mackerel Advent Calendar 2019 22日目のエントリです。Mackerelでは、ホストやミドルウェアのメトリックをグラフとして可視化することができます。日々のシステム状況の把握やキャパシティプランニング、トラブルシューティングの際に参照するのが主な用途だと思いますが、システムの運用を開始する前の負荷テストにおいても活用することができます。本エントリでは、時系列データベースGraphiteの書き込みパフォーマンスの負荷テストを例にして、Mackerelによる負荷テスト中のメトリックの可視化とそれを活用してチューニングする過程を紹介します。ひとつ注意点があります。Mackerelではメトリックを1分間隔で保持するので、負荷計測を短時間（数十秒〜数分）で行うケースではデータの解像度が足らずうまく利用することができません。Graphiteはじめに計測対象のGraphiteについて説明します。コンポーネントで構成される時系列データベースです。Graphite-WebCarbonWhisper各コンポーネントの連携については次の図が参考になります。https://raw.githubusercontent.com/graphite-project/graphite-web/master/webapp/content/img/overview.pngGraphiteにおいてメトリックを受信して書き込みを行うのはCarbonです。Carbonはデーモンとして稼働し、ネットワーク経由でメトリックを受信してそれをWhisper形式でファイルに書き込みます。負荷テストではCarbonに対して大量のメトリックを送信することで負荷計測を行います。検証環境サーバ構成サーバMicrosoft Azure Standard F4s_v2（4 vcpus, 8 GiB memory）データディスク（Graphitデータ保存先）Premium SSD Managed Disks  P30 （1024 GiB, 5000IOPS, 200 MB/second）OSUbuntu Server 18.04 LSTMackerelメトリックプラグインGraphiteのメトリック可視化のためにmackerel-plugin-graphiteを使います。プラグインです。今回の負荷テストで主に確認するメトリックは次の２つです。Carbon Metrics Received受信したメトリックのデータポイントの数Carbon Committed Pointsディスクにフラッシュしたメトリックのデータポイントの数受信したメトリックを遅延なくディスクにフラッシュできているかという、Graphiteの書き込みパフォーマンスに直結する値がここから読み取ることができるためです。負荷テストツールhaggarというCarbonの負荷テストツールを使います。以下は負荷調整に利用するオプションのデフォルトです。$ haggar \    -agents=100 \    -flush-interval=10s \    -metrics=10000 \    -jitter=10s \    -metrics=10000 \    -spawn-interval=10sデフォルトは次のような負荷のかけ方になります。10秒（+最大10秒のゆらぎ）ごとに並列数を増やし（-spawn-interval, -jitter）最大100並列で（-agents）それぞれ10000個のメトリックを（-metrics=10000）10秒間隔でフラッシュする（-flush-interval）構築手順負荷テスト開始時点までの構築手順を以下に載せています。https://gist.github.com/shiimaxx/53b8dfe76b5f13bbff9f75777293e0f4負荷計測それではhaggarで負荷計測しつつ、Mackerelのグラフを見てみます。haggarは次のように実行しました。最大並列数を300でそれぞれ2000個のメトリックをフラッシュします。その他はデフォルトです。$ haggar -agents=300 -metrics=2000 -carbon=localhost:2003負荷計測 - １回目負荷計測を１時間程度実行したあとのグラフです。※  データディスク（Graphitデータ保存先）のWrite数のグラフ送信側の並列数が増えるにつれてCarbon Metrics Receivedが200万程度まで増えていっていますが、それと比較してCarbon Committed Pointsは1万くらいにしかなっていません。サーバリソースのグラフを見ると、CPUリソースは１コア分しか利用していません。また、データディスクは5000IOPSが上限のものを利用していますが、グラフでは10〜60IOPS程度です。サーバリソースにまだ余裕があることから、サーバの性能不足によってGraphiteのデータ書き込みが追いついていないというわけではないことがわかります。このようなケースでは、何かしらのエラーやミドルウェアの設定によってパフォーマンスが制限されている場合はあります。Graphiteでは、MAX_UPDATES_PER_SECONDというパラメータでメトリック更新のためのディスク書き込みのレートを設定することができます。デフォルト値は500です。設定値をinfにすると書き込みレートの制限がされません。また、メトリックの新規作成時の書き込みレートも同じように制限しないようにします。/etc/carbon/carbon.conf[cache]...MAX_UPDATES_PER_SECOND = infMAX_CREATES_PER_MINUTE = inf負荷計測 - ２回目設定変更後に再度負荷計測を実行します。負荷計測を１時間程度実行したあとのグラフです。※  データディスク（Graphitデータ保存先）のWrite数のグラフ送信側の並列数が増えるにつれてCarbon Metrics Receivedが300万程度まで増えていっています。先ほどとは違いCarbon Committed Pointsも300万程度まで増えており、受信したメトリックをしっかりディスクにフラッシュできているようです。CPUはiowaitの割合が少し目立ってきました。ディスクは2000〜3000IOPSを推移しています。Graphiteの書き込みパフォーマンスは特に問題ありませんが、せっかく4vcpusのVMを利用しているので、vcpuの数分carbon-cacheのインスタンス起動してcarbon-relayでバランシングする構成に変更したときにどのような傾向になるかも見てみます。/etc/carbon/carbon.conf[cache:b]LINE_RECEIVER_PORT = 2103PICKLE_RECEIVER_PORT = 2104CACHE_QUERY_PORT = 7102[cache:c]LINE_RECEIVER_PORT = 2203PICKLE_RECEIVER_PORT = 2204CACHE_QUERY_PORT = 7202[cache:d]LINE_RECEIVER_PORT = 2303PICKLE_RECEIVER_PORT = 2304CACHE_QUERY_PORT = 7302[relay]RELAY_METHOD = consistent-hashingDESTINATIONS = 127.0.0.1:2004:a, 127.0.0.1:2104:b, 127.0.0.1:2204:c, 127.0.0.1:2304:d/lib/systemd/system/carbon-cache@.service[Unit]Description=Graphite Carbon Cache %iAfter=network.targetDocumentation=https://graphite.readthedocs.io[Service]Type=forkingStandardOutput=syslogStandardError=syslogExecStart=/usr/bin/carbon-cache --config=/etc/carbon/carbon.conf --instance %i --pidfile=/var/run/carbon-cache-%i.pid --logdir=/var/log/carbon/ startPIDFile=/var/run/carbon-cache-%i.pid[Install]WantedBy=multi-user.targetcarbon-cacheを停止して、carbon-cache@a 〜 carbon-cache@dとcarbon-relay@aを起動する。$ sudo systemctl stop carbon-cache$ sudo systemctl start carbon-cache@a$ sudo systemctl start carbon-cache@b$ sudo systemctl start carbon-cache@c$ sudo systemctl start carbon-cache@d$ sudo systemctl start carbon-relay@a負荷計測 - ３回目メトリックの送信先をcarbon-relay（2013ポートで待受け）にします。$ haggar -agents=300 -metrics=2000 -carbon=localhost:2013carbon-cacheのグラフは各インスタンスの値が個別の線で表示されていますが、各インスタンスの値の合計がわかりやすいようにグラフを積み上げにしています。負荷計測を１時間程度実行したあとのグラフです。※  データディスク（Graphitデータ保存先）のWrite数のグラフCarbon Metrics ReceivedとCarbon Committed Pointsは先ほどと同じで300万程度まで増えています。CPUはidle以外の合計が400%近くまで増えましたが、その半分をiowaitが占めています。ディスクは5000IOPSが続いており、I/O性能を上限まで使い切れています。さきほどよりIOPSが増えている理由は特に調べていませんが、carbon-cacheのインスタンスを４つにしたことで、今まで１つのプロセスで書き込みをしていたのが４つのプロセスで書き込みするようになったため、書き込みのマージが効きづらくなったのかもしれません。まとめ少し前に業務でGraphiteサーバの負荷テストをやりまして、そのときはモニタリングは独自基盤を利用していたのですが、Mackerelでもできそうということでやってみました。エージェント・メトリックプラグイン・ダッシュボードがいい感じに連携していて、本当に少しの作業でグラフが作れてとても便利ですね。参考文献Monitoring with Graphitehttp://obfuscurity.com/Tags/GraphiteMackerelを支える時系列データベース技術

Mackerelで負荷テスト中のリソースモニタリングを行う

Go5 Advent Calendar 2019 12日目のエントリです。ライブラリにはカスタマイズ可能なインターフェースが提供されている場合があります。それを活用することで、ライブラリが提供している標準の関数では実現できない機能や処理を実装することができます。本エントリでは、Goの標準ライブラリであるflagパッケージとencoding/jsonパッケージを例にして紹介します。flagflagパッケージではflag.Var()によって、値のパース処理と変数へのバインド処理をカスタマイズしたコマンドラインフラグを定義することができます。文字列や数値などを対応するGoの型の変数にバインドするだけであれば、string型の変数にバインドするflag.String()、int型の変数にバインドするflag.Int()などのflagパッケージで提供されている関数を使えばよいのですが、スライスや独自型の変数にバインドしたい場合は、flag.Var()を使う必要があります。flag.Var()は、第１引数にflag.Valueインターフェースを実装した独自型の値を渡します。flag.Valueインターフェースは次のように定義されています。type Value interface {    String() string    Set(string) error}https://golang.org/pkg/flag/#ValueポイントはSet()です。Set()はflag.Parse()を呼び出したときに内部的に呼び出され、コマンドフラグで渡された値を入力として、それをレシーバ自身にセットする関数です。ここにカスタマイズした処理を実装していきます。ひとつ例を挙げます。-tag key:val のように:区切りのKey-Value形式の値をとって、それをKey、Valueをそれぞれフィールドとしてもつ構造体にバインドするコマンドラインフラグを実装してみます。以下がソースコードです。Go Playground上で動作確認できるように、flag.FlagSetを利用している点に注意してください。package mainimport (        "errors"        "flag"        "fmt"        "strings")type Tag struct {        Key   string        Value string}func (t *Tag) String() string {        return fmt.Sprintf("%s:%s", t.Key, t.Value)}func (t *Tag) Set(val string) error {        if !strings.Contains(val, ":") {                return errors.New("':' must be contain")        }        kv := strings.Split(val, ":")        if kv[1] == "" || len(kv) != 2 {                return errors.New("must be specified in 'key:value' format")        }        t.Key, t.Value = kv[0], kv[1]        return nil}func main() {        var tag Tag        fs := flag.NewFlagSet("ExampleValue", flag.ExitOnError)        fs.Var(&tag, "tag", "tag")        fs.Parse([]string{"-tag", "hoge:fuga"})        fmt.Printf("Key: %s, Value: %s\n", tag.Key, tag.Value)}https://play.golang.org/p/dCwpA8zFxVt-tagフラグで渡された値をバインドするためのフラグ型としてTag構造体を定義しました。これは、flag.Valueインターフェースを実装しています。Set()では入力値の検証を行い、問題ない場合はレシーバ自身にその値をセットします。入力値の検証では、「:が含まれているか」、「hoge::fugaのような不正な形式になっていないか」をチェックしています。Tag 型の変数であるtagをfs.Var()の第１引数に渡してコマンドラインフラグを定義しています。このあと、fs.Parse()を呼び出したタイミングで、内部的にTag構造体のSet()が呼び出されます。ここでエラーが返された場合は、コマンドラインフラグのパースエラーとして次のようなエラーが表示されます。invalid value "hoge::fuga" for flag -tag: must be specified in 'key:value' formatencoding/jsonencoding/jsonパッケージには、Goの値をJSONデータにするjson.Marshal()とJSONデータをGoの値として取り扱うためのjson.Unmarshal()があります。json.Unmarshal()に着目して、json.Unmarshalerインターフェースを実装した型を利用することで、JSONデータからGoへの変換処理をカスタマイズする例を紹介します。先程と同様に値がkey:val形式であるJSONのフィールド(Strings)を、Goの独自型にバインドするとします。json.Unmarshal()は、第２引数にinterface()を渡すことができます。これがJSONデータをバインドする先の変数になります。json.Unmarshal() は第２引数の値がjson.Unmarshalerインターフェースを実装している場合にUnmarshalJSON()を呼び出します。UnmarshalJSON()で任意のJSONデータの入力を受けて自身の型に変換するように実装することで、先程のflagパッケージの例と同じように独自型の変数へのバインドができます。以下がソースコードです。package mainimport (        "encoding/json"        "errors"        "fmt"        "log"        "strings")type Tag struct {        Key   string        Value string}func (t *Tag) UnmarshalJSON(b []byte) error {        val := strings.Trim(string(b), `"`)        if !strings.Contains(val, ":") {                return errors.New("':' must be contain")        }        kv := strings.Split(val, ":")        if kv[1] == "" || len(kv) != 2 {                return errors.New("must be specified in 'key:value' format")        }        t.Key, t.Value = kv[0], kv[1]        return nil}type Obj struct {        Name      string `json:"name"`        CustomTag Tag    `json:"custom_tag"`}func main() {        blob := `{"name": "dummy object", "custom_tag": "hoge:fuga"}`        var obj Obj        if err := json.Unmarshal([]byte(blob), &obj); err != nil {                log.Fatal("error: ", err)        }        fmt.Printf("Key: %s, Value: %s\n", obj.CustomTag.Key, obj.CustomTag.Value)}https://play.golang.org/p/R-o_LBY6HHfJSONデータのkey:val形式のフィールドをバインドする先の型としてTag構造体を定義しました。TagはUnmarshalerインターフェースを実装しています。入力値の検証とレシーバ自身に値をセットするという点は先程のflagの例と変わりませんので、UnmarshalJSON()の処理は、flagのサンプルコードにおけるSet()とほぼ同じになっています。まとめいずれも特定のインターフェースを実装した型を用意して、そのインターフェースのメソッドにカスタマイズした処理を実装するというパターンでした。​​参考文献https://golang.org/pkg/flag/https://golang.org/pkg/encoding/json/

Goにおけるライブラリのカスタマイズ性の活用

GitHub - shiimaxx/txtmanip外部コマンドを利用したテキスト処理をインタラクティブに実行することができます。ワンライナーを作る練習として使えると思います。デモ実行している様子は次のとおりです。catで標準出力に出力したcombined形式のアクセスログの内容をパイプで渡し、インタラクティブモード内でawk '{print $7}' → sort → uniq -c → sort -nr → head -5を実行してリクエスト数上位5件のURLを出力しています。インタラクティブモードを終了すると、インタラクティブモード中に実行したコマンドをパイプで繋げたワンライナーが出力されます。これを実行することで最終的な結果と同じ内容のものを表示することができます。設定ファイルTOML形式の設定ファイルに設定を記述します。enable_commandsという項目にインタラクティブモード中に実行するコマンドリストを設定することができます。リストにないコマンドは実行することができません。enable_commands = [    "awk",    "cut",    "grep",    "head",    "sed",    "sort",    "tail",    "uniq",    "wc",]実装についてtermbox-goテキストベースのユーザインタフェースを実現するために、GitHub - nsf/termbox-go を使っています。termbox-goではSetCell で位置と文字（rune）を指定してどこになにを描画するかを定義します。これを手続き的に書いていくと非常に分かりづらいコードになってしまうため、そうならないように表示する内容と描画する処理を分けて書くようにしました。MainViewとそれに含まれるInputArea（ユーザの入力が表示される部分）とTextArea（テキスト操作の結果が表示される部分）をそれぞれ構造体として定義しています。表示する内容はそれぞれのフィールドの値として保持します。// MainView represent main viewtype MainView struct {    textArea  TextArea    inputArea InputArea    height    int    width     int}...// InputArea represent input areatype InputArea struct {    text             []byte    error            []byte    cursorPos        int    cursorInitialPos int    prompt           []byte    history          []string    historyPos       int}...// TextArea represent text areatype TextArea struct {    text    []byte    history []string}描画は各構造体に実装した描画用のメソッドで実行するようにしました。描画用のメソッドはフィールドに保持している値をもとにSetCellを実行していきます。以下はTextAreaの描画用メソッドです。func (v *MainView) DrawTextArea() {    y := TextAreaPos    x := 0    for _, t := range v.textArea.text {        if t == byte('\n') {            y++            x = 0            continue        }        termbox.SetCell(x, y, rune(t), ColFg, ColBg)        x++    }}また、MainViewのFlush()メソッドをで、描画用メソッドをまとめて実行するようにしています。func (v *MainView) Flush() error {    if err := termbox.Clear(ColBg, ColBg); err != nil {        return err    }    termbox.SetCursor(v.inputArea.cursorPos, InputAreaPos)    v.DrawBorderLine()    v.DrawInputArea()    v.DrawInputError()    v.DrawTextArea()    return termbox.Flush()}課題元となるテキストやヒストリーをすべて構造体のフィールドの値として保持しており、メモリ効率がよくないと感じています。まとめ何かありましたらIssue、Pull Requestをいただけると嬉しいです。

インタラクティブにテキスト処理を実行できるツールを作った - txtmanip

https://github.com/shiimaxx/altercodeコマンドの実行結果が正常（終了ステータスが0）の場合でも、特定の条件の場合は任意の終了ステータスにしたいというときに使えます。ワンライナーやシェルスクリプトでもできるとは思いますが、練習がてらGoで書きました。とある環境のCIパイプラインで、WARNINGなどの警告は出ているがコマンドの終了ステータスが0であるためCIをパスしてしまっているものを強制的に失敗させたいという目的があって作りました。使い方は次のとおりです。この場合、commadの標準出力に「warning」が含まれると終了ステータスが3になります。altercode -contain warning -exit-code 3 -- command現状はコマンドの標準出力に特定の文字列が含まれているかをチェックすることができます。実装についてオプションのパース引数に指定するコマンドはオプションを含むこともあると思いますので、--によってオプション部分の終了を明示できるようにしています。--でオプションの終了を示す方法は、Bashのビルトインコマンドでも使われています。man bash に以下の記載があります。 --        A -- signals the end of options and  disables  further  option                 processing.   Any  arguments after the -- are treated as file-                 names and arguments.  An argument of - is equivalent to --.Goの標準パッケージでCLIツールのオプションのパースを行うflagでは、--をオプションの終了として解釈するため特別な実装は必要ありません。FlagSet.Parse()でパースすると--より前をオプションとしてパースしてくれます。flagパッケージのGoDocに以下の記載があります。Flag parsing stops just before the first non-flag argument ("-" is a non-flag argument) or after the terminator "--".引数に指定したコマンドの終了ステータスの取得引数に指定したコマンドがエラーになり、終了ステータスが0以外の場合はそのステータスコードで終了します（コマンドの実行自体ができない場合は別です）。実際のコードは次のようになっています。    out, err := cmd.Output()    if err != nil {       if exitErr, ok := err.(*exec.ExitError); ok {          fmt.Fprintf(c.errStream, string(exitErr.Stderr))          if ws, ok := exitErr.ProcessState.Sys().(syscall.WaitStatus); ok {             return ws.ExitStatus()          }          return ExitCodeError       }       :execパッケージのCmd.Output()でコマンドを実行しています。Cmd.Output()は内部的にCmd.Run()を実行しており、これはコマンドの実行に問題があった場合に*exec.ExitError型のエラーを返します。コマンドの実行結果に関する情報は、*exec.ExitError型に埋め込まれている*os.ProcessStateのSys()メソッドで取得します。その後、取得したものをsyscall.WaitStats型にキャストし、ExitStatus()メソッドを呼び出すことで終了ステータスを取得できます。まとめちょっとしたツールの紹介でした。参考文献https://golang.org/pkg/os/exec/https://golang.org/pkg/os/#ProcessState.Syshttps://golang.org/pkg/syscall/#WaitStatus.ExitStatusWhat does “--” (double-dash) mean? (also known as “bare double dash”)

コマンドの終了ステータスを操作するツールを作った - altercode

このエントリは Go Advent Calendar 2018 12日目の記事です。SlackにはInteractive frameworkという仕組みがあります。これによりButtonやMenuなどのインターフェースをユーザに提供することができます。このエントリでは、Dialogsを使ったSlack AppをGoで書くときの流れを紹介します。サンプルデリバリーのコーヒーを注文するCoffeebotを題材とします（実際に注文はしません）。以下の流れで利用します。@coffee orderでBotを呼び出しOrder Coffeeボタンをクリックコーヒーの注文フォームを入力コーヒーの種類を選択カスタマイズの内容を入力（オプション）配達希望時間を入力注文受付のメッセージを受け取るなお、Coffeebotは以下のPythonのサンプル用のAppをカスタマイズして実装しています。https://github.com/slackapi/python-dialog-exampleまた、Goで実装するにあたり、以下のリポジトリのコードをベースとして使わせていいただいています。https://github.com/tcnksm/go-slack-interactiveCoffeebot自体のコードはこちらのリポジトリにあります。https://github.com/shiimaxx/slack-coffeebotSlack Appの作成ドキュメントに手順がありますので詳しい説明は省略します。https://api.slack.com/slack-apps次の2点は実施しておく必要があります。Appに紐づくBot Userの作成Interactive Componentsの有効化Bot Userは、Slackチャンネル上におけるユーザへのインタフェースとして利用します。Interactive ComponentsはButtonやDialogを利用するために有効にする必要があります。エストを受け付けるRequest URLも指定します。Request URLのドメイン名とエンドポイントは実際のアプリケーションにあわせて設定してください。SlackライブラリSlackライブラリはnlopes/slackを利用しています。2018/12/12現在の最新リリースは、v0.4.0です。このリリースではDialogsに関するAPIはEXPERIMENTALですのでご注意ください。masterブランチのHEAD を利用しています。Dialogsを使ったSlack Appの処理フローSlack Appは次の流れで処理を行うようにします。ユーザからInteraction Message、もしくはSlash CommandsによるPOSTリクエストを受けるdialog.open APIを呼び出して、POSTリクエストのJSONデータに含まれるtrigger_idとフォームをユーザに提供するユーザによるフォーム入力の完了後のPOSTリクエストを受けるフォームに入力された内容をもとに何らかの処理を行い、必要に応じてメッセージを投稿するユーザからInteraction Message、もしくはSlash CommandsによるPOSTリクエストを受けるDialogsを呼び出すためには、Button, Menuもしくは/coffeeのようなSlash Commandsをトリガーにする必要があるため、まずはこれらのPOSTリクエストを受け付けるようにします。POSTリクエストはSlack AppのInteractive Componentsを有効化する際に設定したRequest URL宛に送られます。エストが送られてきますが、これはButton, MenuともSlash CommandsともJSONデータの構造が異なります。nlopes/slackでは、slack.InteractionCallback という、ButtonとDialogのどちらのPOSTリクエストのJSONデータでもパースできるようになっているstructが定義されていますのでこれを利用します。JSONデータがButtonによるものかDialogによるものかの判別は、typeフィールドの値で行なえます。var message slack.InteractionCallbackif err := json.Unmarshal([]byte(jsonStr), &message); err != nil {    log.Print("json unmarshal message failed: ", err)    w.WriteHeader(http.StatusInternalServerError)    return}//  :if message.Type == "interactive_message" {    // Order Coffeeボタンの入力を受け付けてフォームを表示する} else if message.Type == "dialog_submission" {    // フォームの入力を受け付けて何かする}dialog.open APIを呼び出して、POSTリクエストのJSONデータに含まれるtrigger_idとフォームをユーザに提供するtrigger_idはslack.InteractionCallback型のmessageのフィールドにあるので、これを使えばOKです。フォームはslack.Dialogとして定義します。Coffeebotでは次のようにしています。func makeDialog(userID string) *slack.Dialog {    return &slack.Dialog{        Title:       "Request a coffee",        SubmitLabel: "Submit",        CallbackID:  userID + "coffee_order_form",        Elements: []slack.DialogElement{            slack.DialogInputSelect{                DialogInput: slack.DialogInput{                    Label:       "Coffee Type",                    Type:        slack.InputTypeSelect,                    Name:        "mealPreferences",                    Placeholder: "Select a drink",                },                Options: []slack.DialogSelectOption{                    {                        Label: "Cappuccino",                        Value: "cappuccino",                    },                    {                        Label: "Latte",                        Value: "latte",                    },                    {                        Label: "Pour Over",                        Value: "pourOver",                    },                    {                        Label: "Cold Brew",                        Value: "coldBrew",                    },                },            },            slack.DialogInput{                Label:    "Customization orders",                Type:     slack.InputTypeTextArea,                Name:     "customizePreference",                Optional: true,            },            slack.DialogInput{                Label:       "Time to deliver",                Type:        slack.InputTypeText,                Name:        "timeToDeliver",                Placeholder: "hh:mm",            },        },    }}dialog.open APIの呼び出しはslack.ClientのOpenDialogContext（もしくはOpenDialog）メソッドでできます。trigger_idとフォーム(dialog)を引数にします。if err := s.slackClient.OpenDialogContext(context.TODO(), message.TriggerID, dialog); err != nil {    log.Print("open dialog failed: ", err)    w.WriteHeader(http.StatusInternalServerError)    return}ユーザによるフォーム入力の完了後のPOSTリクエストを受ける必要に応じて入力内容のチェックをするとよいでしょう。Coffeebotでは、注文フォームで次の項目を入力します。コーヒーの種類を選択カスタマイズの内容を入力（オプション）配達希望時間を入力「コーヒーの種類を選択」は選択式なのでチェックは必要ありません。「カスタマイズの内容を入力」もTextAreaによる自由記入欄なのでチェックは不要でしょう。「配達希望時間」については、時刻以外の入力があったり、現在時刻より前の時間を指定されると正常にオーダーを受け付けられないので、チェックしておいたほうがよさそうです。Coffeebotでは次のような関数を用意してチェックしています。（厳密ではなかったり冗長なところもありますがご了承ください。）var errInvalidInput = errors.New("invalid input")var errTimePreference = errors.New("time should be after 30 minutes ago")    func validateTime(t string) error {    const format = "15:04"    parsedTime, err := time.Parse(format, t)    if err != nil {        return errInvalidInput    }    var jst = time.FixedZone("UTC+9", 9*60*60)    now := time.Now().In(jst)    addLocationJST := func(t time.Time) time.Time {            return time.Date(now.Year(), now.Month(), now.Day(), t.Hour(), t.Minute(), t.Second(), t.Nanosecond(), jst)    }    parsedTime = addLocationJST(parsedTime)    if parsedTime.Before(now.Add(time.Minute * 30)) {        return errTimePreference    }     return nil}入力チェックで不正な値があった場合は、エラー内容をレスポンスで返す必要があります。JSONデータで返します。また、ステータスコードは200 OKにします。{  "errors": [    {      "name": "email_address",      "error": "Sorry, this email domain is not authorized!"    },    {      "name": "username",      "error": "Uh-oh. This username has been taken!"    }  ]}Coffeebotの例です。t := message.Submission["timeToDeliver"]if err := validateTime(t); err != nil {    log.Print("validate error: ", err)    type validateError struct {        Name  string `json:"name"`        Error string `json:"error"`    }    type validateErrorResponse struct {        Errors []validateError `json:"errors"`    }    w.Header().Add("Content-type", "application/json")    json.NewEncoder(w).Encode(&validateErrorResponse{        []validateError{{Name: "timeToDeliver", Error: err.Error()}},    })    return}正しくレスポンスを返すことで、次のようにフォームにエラーメッセージを表示することができます。フォームに入力された内容をもとに何らかの処理を行い、必要に応じてメッセージを投稿するフォームの入力内容が問題ない場合は、200 OKの空レスポンスによってユーザに伝える必要があります。これは3秒以内にレスポンスするか、アプリケーション側の処理に時間を要する場合はresponse_urlを利用してレスポンスを遅延して返すこともできます。Coffeebotでは時間のかかりそうな処理は新たに起動したgoroutineで実行して、レスポンスは即時返すようにしています。このあたりはGoならではだと思います。go func() {    time.Sleep(time.Second * 5)　// 注文の処理を想定したスリープ    attachment := slack.Attachment{        Text:       ":white_check_mark: Order received!",        CallbackID: s.botID + "coffee_order_form",    }    options := slack.MsgOptionAttachments(attachment)    if _, _, err := s.slackClient.PostMessage(message.Channel.ID, options); err != nil {        log.Print("[ERROR] Failed to post message")    }    return}()   w.Header().Add("Content-type", "application/json")w.WriteHeader(http.StatusOK)fmt.Fprintf(w, "")まとめDialogsを活用すればSlack上だけで色々なことが完結させられてよさそうですね。今回は入力を受け付けてレスポンスするだけの簡単なアプリケーションでしたが、ステートを持たせるようなものを作る場合は色々と気にする点が増えるのでもう少し複雑になります。そのあたりは公式ドキュメントをご覧いただければと思います。参考文献https://api.slack.com/dialogshttps://api.slack.com/interactive-messagesGolangでSlack Interactive Messageを使ったBotを書くhttps://github.com/slackapi/python-dialog-examplehttps://github.com/tcnksm/go-slack-interactive

GoでDialogsを使ったSlack Appを作る

このエントリは Gopher道場 Advent Calendar 2018 5日目の記事です。Goではエラーをerror型の値として扱います。errorはビルトインのインタフェース型として次のように定義されています。type error interface {    Error() string}https://golang.org/pkg/builtin/#errorGoではインタフェース宣言時に定義したメソッドリストを実装することでインタフェースを実装します。つまり、任意の型にError() stringをメソッドとして実装すれば、独自のエラー型のerrorとして扱うことが可能になります。標準パッケージ net のエラー型例えば標準パッケージのnetでは、OpError, DNSErrorなどの様々な独自のエラー型が定義されています。これらのエラー型は、エラー情報を格納するための構造体フィールドがあり、エラーに関するコンテキストを持つことができます。また、netパッケージのエラー型はnet.Errorというインタフェース型を実装するかたちで定義されており、errorインタフェースの埋め込みの他に、エラーの性質を判別するためのTimeout() bool, Temporary() boolというメソッドを提供します。type Error interface {    error    Timeout() bool   // Is the error a timeout?    Temporary() bool // Is the error temporary?}https://golang.org/pkg/net/#Errorエラーにコンテキストとエラーの性質を判別するメソッドをもたせることによって、エラーよって処理を変えるエラーハンドリングが可能になります。また、ネットワークエラーをあらわすエラーをnet.Errorインタフェースで集約しているため、次のように比較的スッキリしたコードで記述できます。if err != nil {    if nerr, ok := err.(net.Error); ok && nerr.Temporary() {        // リトライする処理    } else {        log.Fatal(err)    }}既存のエラーにコンテキストを加える例として、次のようなWebリクエストを実行した結果を返す関数があるとします。func SomeFunc(url string) (string, error) {    resp, err := http.Get(url)    if err != nil {        return "", err    }    if resp.StatusCode != http.StatusOK {        return "", errors.New("HTTP status error: ". resp.StatusCode)    }    body, err := ioutil.ReadAll(resp.Body)    defer resp.Body.Close()    if err != nil {        return "", err    }    return string(body[:]), nil}この関数を別パッケージから呼び出す際には次のようなコードになると思います。resp, err := SomeFunc("http://example.com")if err != nil {    log.Fatal(err)}上記のプログラムの追加の要件として、HTTPステータスが500 Internal Server Errorの場合にリトライ処理を実装するとします。呼び出し元のコードでリトライ処理を行うためには、返されたエラーからHTTPステータスをチェックする必要があります。SomeFunc()ではresp.StatusCode != http.StatusOKでHTTPステータスのチェックを行い200 OKでない場合はエラーを返していますが、HTTPステータスの情報はエラーメッセージにしか含まれていません。エラーメッセージの内容をチェックしてエラーハンドリングする処理を書くこともできますが、あまりよいやり方ではなさそうです。また。SomeFunc()の戻り値にHTTPステータスを追加することもできますが、APIが壊れるためこれもよくないでしょう。このような場合に先程のnetパッケージで定義されていたエラー型のようにコンテキストをもたせる方法が有効です。先程のコードを書き換えてみます。具体的には、net.ErrorにならってTemporary()メソッドをもつHTTPErrorインタフェースと、それを実装するエラー型httpStatusErrorを定義します。httpStatusErrorはフィールドにHTTPステータスコードをもたせます。type HTTPError interface {    error    Temporary() bool}type httpStatusError struct {    statusCode int}func (e *httpError) Error() string {    return fmt.Sprint("HTTP status error: ", e.stautsCode)}func (e *httpError) Temporary() bool {    return e.stautsCode == http.StatusInternalServerError}HTTPステータスのチェックでは、httpStatusError型のエラーを返すようにします。func SomeFunc(url string) (string, error) {    resp, err := http.Get(url)    if err != nil {        return "", err    }    if resp.StatusCode != http.StatusOK {        return "", &httpStatusError{stautsCode: resp.statusCode}    }    // 以下略}呼び出し元では次のようにエラーハンドリングすることが出来ます。resp, err := SomeFunc("http://example.com")if err != nil {    if herr, ok := err.(HTTPError); ok && herr.Temporary() {        log.Errorf("retry...")        // リトライ処理    }    log.Fatal(err)}まとめインタフェースによってエラーを判別できるようにしておくことで、呼び出し側が特定のエラー型に依存することを避けられます。参考文献Error handling and GoGolangのエラー処理とpkg/errorshttps://dave.cheney.net/paste/gocon-spring-2016.pdfDon’t just check errors, handle them gracefully