文字列の連結をしない

追記 (2022-06-12)

この記事はstrconv.Itoaを大量に使わないというタイトルで、strconv.Itoaを使うことが重い原因のように書いていましたが 申し訳ありません、それは間違いだったので結論を直しています。

概要

Goで競プロをやるときにハマった事のメモです。

ABC233のEでTLEを出した時の対処となります。

結論

文字列の連結（r+="hoge"のような）をN>= 105くらいより上のケースで使うとTLEになる場合があるので避ける。 文字を結合したければ[]byteで扱うか、strings.Joinを利用すれば良い。strconv.Atoiとstrconv.Itoaは使っても問題になることは少ないはず。

詳細

https://atcoder.jp/contests/abc233/submissions/28133985

以下TLEになったソースです。

func main() {
 
    defer flush()
 
    o := ""
 
    x := ns()
    ns := make([]int, len(x))
    sum := 0
    for i, v := range x {
        ns[i] = atoi(string(v))
        sum += ns[i]
    }
    rs := make([]int, len(ns)+1)
    t := 0
    for i := 0; i < len(ns); i++ {
        rs[i] = (sum + t) % 10
        t = (sum + t) / 10
        sum -= ns[len(ns)-i-1]
    }
    if t != 0 {
        o += itoa(t)
    }
    for i := len(ns) - 1; i >= 0; i-- {
        o += itoa(rs[i])
    }
 
    out(o)
}

自作関数を所々使ってますが、入出力はバッファリングしているのと、あとstrconv.Atoi、strconv.Itoaはそれぞれエラー処理が煩雑なのと書く量を減らすためatoi,itoaにラップしてます。

メインのロジックは間違っていないと思っており(実際に間違っていませんでした)、atoiとitoaのどちらかがまずいのだろうと目星をつけました。

atoiの方は

        ns[i] = atoi(string(v))

を

        ns[i] = int(v) - 48

に変えましたが効果はありませんでした。それはそのはずで、実際にstrconv.Atoiの中でも

        n := 0
        for _, ch := range []byte(s) {
            ch -= '0'
            if ch > 9 {
                return 0, &NumError{fnAtoi, s0, ErrSyntax}
            }
            n = n*10 + int(ch)
        }

上記のような処理を内部でやっているので実質やっていることは同じです。

問題はitoaの方で500000個の要素に対し全てにitoaをやるのはかかる時間が大きすぎるようです。 ここは最終的に答えが出力されれば良いので、

    if t != 0 {
        o += itoa(t)
    }
    for i := len(ns) - 1; i >= 0; i-- {
        o += itoa(rs[i])
    }
 
    out(o)

ここをoutに対してoutwolnという関数(without ln、いい名称ではないがlnをつけるケースがほとんどなので…)を作り

func out(v ...interface{}) {
    _, e := fmt.Fprintln(wtr, v...)
    if e != nil {
        panic(e)
    }
}
func outwoln(v ...interface{}) {
    _, e := fmt.Fprint(wtr, v...)
    if e != nil {
        panic(e)
    }
}

以下のようにすればACでした！

    if t != 0 {
        outwoln(t)
    }
    for i := len(ns) - 1; i >= 0; i-- {
        outwoln(rs[i])
    }
    out("")

改めてstrconv.Itoaの中身を見てみましたが処理が数値が10未満、100未満、それ以上と別れていて100未満の場合は以下のように文字列から取っているようです。面白いですね。早そうですが毎回スライスを扱うので大量に行うと重いようです。

func small(i int) string {
    if i < 10 {
        return digits[i : i+1]
    }
    return smallsString[i*2 : i*2+2]
}

const smallsString = "00010203040506070809" +
    "10111213141516171819" +
    "20212223242526272829" +
    "30313233343536373839" +
    "40414243444546474849" +
    "50515253545556575859" +
    "60616263646566676869" +
    "70717273747576777879" +
    "80818283848586878889" +
    "90919293949596979899"

const digits = "0123456789abcdefghijklmnopqrstuvwxyz"

（追記 2020-06-16） と記事を書いた当初はstrconv.Itoaを悪者にしていましたが、初めのソースを以下のように直すと普通に通りました。

    r := make([]string, len(ns))
    for i := len(ns) - 1; i >= 0; i-- {
        r[len(ns)-i-1] = itoa(rs[i])
    }
    o += strings.Join(r, "")

原因は文字列結合だったようです。

改めてなぜ文字列結合が遅いかを調べたところ、以下にわかりやすい解説がありました。毎回文字列を作り直しているんですね…。O(N2)になるのかと思います。

Goでは文字列連結はコストの高い操作

高速にするには[]byteで扱うのが正解、次点でstrings.Join()となります。

Goの文字列結合のパフォーマンス

なので最終的にこうして

    r := make([]byte, len(ns))
    for i := len(ns) - 1; i >= 0; i-- {
        r[len(ns)-i-1] = byte('0' + rs[i])
    }
    o += string(r)

今までで一番早くなりました！文字列結合にしていると2s以上かかっていたものが37msですみました。

競プロ典型 90 問をGoで解く

今更ですが競技プログラムに手を出し始めて半年くらいになります。AtCoderをやっていて、もうすぐ水色になれそうな緑です。言語についてはC++やPythonを使うべきなんだろうなと思いつつGo書くのが楽しいのでGoでやっています。

 

競プロの力をつけるにあたって競プロ典型90問という素晴らしいコンテンツがあるのですが、
それを全てGoで書いてみました。

競プロ典型 90 問 - AtCoder

本とかネットとかで調べつつやりましたが自力で解説を見る前にACを出せたのは413点満点中299点でした。★6と★７に苦しめられましたが良い思い出です。

 

おそらくGoで全部やった方はいなさそうです。90番目の問題は現時点で誰一人GoでACを出していません。私も模範解答を写せば言えると思いきやTLEが解消できず、いずれトライしたいと思っています。それ以外は全てACを出せました。

以下自分で解けた問題、一言感想、書いたコードをのっけますので同じくらいのレベルの人や、同じことをGoでやろうとしたの参考になれば幸いです。一応感想はアルゴリズムのことを述べていてネタバレになるので、これから何もみずにやるという人は見ないようにしてください。

 

全部やり切るのは大変でしたがとても勉強になりました。素晴らしいコンテンツを用意していただいた企画者のE869120様に非常に感謝しております。ありがとうございます！

f:id:drunkturtle:20211226121517p:plain

f:id:drunkturtle:20211226121456p:plain

 

GopherCon2020を雑多に振り返る

GopherCon2020終わりました。ワークショップから最終日まで実質5日間どっぷりGoに浸って非常に楽しかったです！振り返って色々な事を雑多にまとめていきたいと思います。セッションを再度見たり、思考を整理しつつ加筆修正していくかと思います。

ワークショップについて

Serverless GoとDebugging Techniques for Goに参加しました。今回ワークショップどちらも良かったです。

Serverless Go

Serverless Goはタイトルの通りサーバレスで動くSlackアプリケーションををAWSで動かすというもので、今までなんとなく難しそうで敬遠してたものが、あ、これならできそうに変わりました。実際にサンプルアプリをハンズオンで作るのですが、まっさらな状態から20分ほどでデプロイできてしまうのに驚きました。これでなんかしらChatOPSのツールを作りたいという意欲が湧きました。

GitHubに資料も公開されています。

GitHub - jboursiquot/serverless-go-orchestration-on-aws-course: Serverless Go Orchestration on AWS Course

Debugging Techniques for Go

みっちりDelveを使いこなすというのをメインとして、それを様々な環境に設定したり、Deterministic debuggingについて説明したり、最後にちょっことpprofの話といった感じでした。Delveを作った方が講師の一人でした、すごい…。DelveについてはCLI上でやるというのがあまりイメージがつかず、printデバッグのみしかしてこなかったのですが、まずは自分の環境に中にセットアップしてみて色々試したいという意欲、使えそうというイメージが持てました。

こちらもありがたく資料が公開されており、かつ練習用のプログラム(debugme)もあり素敵です。

GitHub - jasonkeene/debugging-workshop

自分の中の一押しセッション

楽しい！業務で活かせそう！為になった！など、ワクワクして聞けたセッションをまとめます。主にこれ良かったから見た方がいいよと同僚に薦めたいものです。

一日目

・Typing [Generic] Go
→genericsはまだ劇的に改善されて嬉しい！という腹落ち感を自分の中で持てないでいます。例も多く話もわかりやすかったので、generics周りを追ってない人は今の状況をさっと知るために良いのではと思います。

・The Quest for the Fastest Deployment Time
→どうやってビルドとDeployの時間を少なくしていくか。鮮やかで見てて楽しかった！k8sも触りたい！

二日目
・Common Patterns for Bounds Check Elimination
→すごいシンプルなコードに高速化の余地が残っているのがすごい！

・Building an FM Radio Station with Go
→半分以上物理的なラジオの話でしたが、最後デモで動かしたところ、これすごい！となりました。

・The Fundamentals of OpenTelemetry
→こういうトレース的なものを仕込みたいなと思っていたので参考になりました。

・Field Report: Building a Game Engine for 300 DEFCON Hackers to Smash
→ISUCONを思い返しました。システムを全部Slackにしたというのはスマートだなと思いました。聞いていて楽しかったです。

・How to Write a Self-Hosted Go Compiler from Scratch
→Go Con2019でも発表されたDQNEOさんの登壇！日本で聞いた時も心動かされましたが、それがここでも非常に称賛を持って受け入れられていて嬉しかったです。

三日目

・Functional Programming with Go
→関数プログラミングって無縁だと思っていたけど、Goでもそのパラダイムが実現でき、適応すると非常に効果的なパターンになるものもあり、思っていた以上に面白いセッションでした。

・A Journey to Postgres Productivity with Go
→まさにこれが聞きたかったよというセッション。DB周りは非常に苦しめられているのでここは試したい。

・Crossing the Chasm: Go for the Next Million Users

→長期的な目線での使われる言語と使われなくなる言語の考察、現状のGoの課題、今後Gopherとして何が貢献できるのかが様々な切り口で語られる良セッション だと多います。今後必要なものの一つに、Non-English Speakingとあってその点で参加してこれを伝えることで貢献できるかもしれないと思いました。世界地図のスライドで日本のアイコンがgoconference'19 summer in Fukuokaのラーメンアイコンになっているのに注目。

その他のセッション

微妙だったセッションというわけではなく、自分の中で消化しきれてないもの、内容がマニアックすぎてわからないもの、自分の技術的興味範囲から少し外れているもの、そもそもまだ見れていないものです。あとで見返して一押しセッションに移すかもしれません。もっと理解できるものを増やしたい…。

一日目

・Write Once, Use Many: A Simple & Useful Package to Call Internal HTTP APIs
→HTTPクライアント確かに雑多になるので、参考にしたい
・Go Time Podcast
→最終日のGo Panicは楽しかったです。雑多な話を聞くには自分の英語力がまだ辛い。
・Evolving the Go Memory Manager's RAM and CPU Efficiency
・Build and Test Caching in Go
・Reordering 59 Million New York Times Publishing Assets Using Go and BadgerDB
・Untangling the Monorepo: Moving to Go Modules
・Safety Not Guaranteed - Using unsafe to syscall Windows APIs without CGO
・Implementing Faster Defers

二日目
・A Rainbow of Gophers: Building A More Diverse Community
→コードや技術とは少しかけ離れたdiversityに関する他のセッションとは異色なセッション。メッセージが何か自分の中で掴めていないので、もう一度ちゃんと見てみたい。
・Go is Not Just on Your Server, it's in Your Browser: The Story of and Introduction to Vugu (Go+WebAssembly UI library)

→Wasmも触ってみたい。
・Go Team - Ask Me Anything (AMA)
→目玉セッションのはずで、聞いていたのだけど、眠気と筋書きのなさから頭に残せてない。見返す。
・Deterministically Debugging Go Programs
・Pardon the Interruption: Loop Preemption in Go 1.14

三日目

・Go is Boring... And That's Fantastic!
・Working with Errors
→昨年のエラーのセッションと比べて、1.13で追加されたerror周りの機能をどう使うのかが整理されていたように思う。ちゃんと見返して理解したい。
・Anyone Can Be A Gopher!
・Optimizing Performance using a VM and Go Plugins
・Go Make Something Real – The Potential for Go on the Factory Floor
・করো: Translating Go to Other (Human) Languages, and Back Again

LTに挑戦しました 

www.youtube.com

How I avoid a terrible problem of database.

内容はGoCon Sendaiでやったものをブラッシュアップしてます。

Gormとの付き合い方

去年参加したとき来年はLTするぞと思ってましたが、なんとか果たすことができました！
前回発表された皆様には本当触発されてます。特に@hgsgtkさんをみて、自分も頑張ろうと思ってました。

GopherCon 2019に参加、海外カンファレンスでLT登壇した経験を振り返る - BASEプロダクトチームブログ
といっても、LTがあるのを知ったのがLTの数日前でそれまでは今回はLTないと思っていました。当初は確か5月に募集するとか書いてあった記憶がありましたが、延期されたりバーチャルになったりしたのち、自然消滅したものと思っていました…。

やるまではやはり胃が痛かったです。去年は非常にたくさん発表があったのですが、今回は時間も少なくで一人のウェイトが大きく、こんな場でこの内容でいいんだろう感に苛まれましたが、最終的にはつべこべ言わずやってしまおうと開き直りました。

やってみたら自分の想像以上にWelcomeで、びっくりしました。Discordで反応が出しやすかったのも良かったのでしょうか？自分の名前がGoなのもウケたし、朝まで起きていたのかとか、日本語でコメントをくれた方もいました。本当心温まる瞬間でした。

f:id:drunkturtle:20201116221810p:plain

こんな感じで、Gopherのみんなありがとう！やって良かった！と強く思いました。やった人を暖かく称えるというのは大事ですね。またやりたいな！と思いますもの。

今回自分にとって非常に糧となり自信になりました。そして楽しかったです。日本でもっといろいろ発表できるかたはたくさんいるかと思うので是非来年トライしてみてもらえればと思います！

参加することに価値はあるのだろうか

日本からの参加者は今回10数名だったでしょうか？少ないなと思います。母国語でないという敷居の高さ、時差、後からほぼ全てyoutubeに上がってみれる、などから参加したいという意欲を削るポイントは多いです。各セッションをみても全部が全部面白いかというと決してそうではないです。興味範囲か外れるもの、内容が濃くないもの、英語と内容いずれかもしくは両面でわけがわからないもの、等々。よく練られた書籍なりWeb教材の方の方がためになるかもしれません。

自分がわざわざ参加費を出してもらって参加する意味はあるのだろうかと始まるまでは自問自答していました。自分はそこまで技術的に世に誇る成果も出していないし、Goの最先端を追い求めている人間でもないです。

そんな事を考えつつ悶々と参加した今回のGopherConだったのですが、、、蓋を開けてみたら非常に楽しく、刺激を受けて、終わってみたらかけがえのないものとなりました。その気持ちは収まらずに何かをしたいという方向に向いて居るので十分価値があったと言えるのではないかと思います。

毎日Goの話をシャワーのように浴びて、Goに関わる人と触れ合って、Goの事をずっと考える非日常が5日間も続くわけです。今回を通して、ああこれは教育の場、議論の場、発表の場という面もありつつも、これって本質的には祭りなんじゃないかと今回感じました。

リアルタイムで見るから伝わる雰囲気もあるし、リアルタイムで貼りつくからこそあとで見ようとも思わないであろうセッションも見たりするし、リアルタイムだからこそそこにいる人となんかリンクしたりするし、それが面白いです。

去年は初めてだから楽しかったのであって、今年はそこまでではないだろうと思っていましたが今年も十分楽しめました。もっと興味を持ってくれる人が周りにも増えてみんなで楽しめるようになると良いですね。

TIPS 

 ・今回ほぼ一週間休みをとって、昼寝て夜起きて、jetlagなしで臨もうとしましたが結果としてうまくいかなかったです。どうしても変な時間に起きてしまうし、夜どうしようもなく眠くなります。太陽がなく日の光を浴びないと調整は難しいように思います。逆に戻すのにはそこまで苦労はなかったです。この点で海外カンファレンスは依然辛いですね。

・本当に聞き逃したくないセッションのために、何をすると一番目を覚めるのかを知っておくと良いのかもしれないです。自分の場合ガムやコーヒーより、するめが一番目が覚めることに気付きました。顎痛くなるんですけど。

・今回参加者はDiscord上で交流したのですが活発で面白かったです。Gamingチャンネルでamong usやっていて混じりたかった…。

・Discordだからこそ反応がダイレクトかつスピーディで面白かったです。間違いの指摘とかもさっと入ります。LTもオフラインならさっとやって終わりだったように思います。ここはonlineならではの良いところだなと思いました。

・字幕のテンポがオンラインだからか少し遅かったように思います。個人的には字幕見ていると混乱しました。

今後について 

非常に楽しみつつも技術的に触発された部分、もうちょっと勉強したいなと思った部分、今の仕事をよくするためのアイデア等々沢山得てこれからが大変です。次は長いセッションにチャレンジしたいというよりかは、今回のgophercon含めて色々とためた知見や勉強したことを活用して、今の自分の担当しているプロジェクトをより磨き上げたいという思いが強いです。あと得た知見を伝えて周りを触発できればとも思ってます。

目の前の仕事をしっかりとやって、地力をつけて、成果を出して、そして聞いた人が非常にためになって良かったと思えるセッションをする、というのを目指していきます。

 

Go Conference’20 in Autumn SENDAI 参加レポート

参加レポートです！現地参戦でした。東京から仙台は2hとはいえ、朝一から参加する為に朝4:30起きで眠気との戦いが大きかったです。もし今後登壇してベストを尽くしたいとかなら前日入りは必須ですね。。。

ナイフ1本で行うGoのサバイバル術
スライド 動画

聞いている最中は？？？でした。途中トラブルで少し内容が飛んでしまったのと、自分は既にvim+goplsの組み合わせを利用していたのでいまいち便利さが掴めませんでした。が、一日たって内容を思い出しながら資料を読み返してみると、CLIで何かチェックをしようと考えた時確かに既存のgo listとかのコマンドだと確かに不十分で、利用できる事が何かあるのかもしれないという感じがしました。ただコードジェネレートできるとか、簡単なLintを作れるとかは今一イメージがついていないのでもう少し触ってみて理解する必要がありそうです。

Go on DockerスタイルでのバックエンドAPI
スライド 動画

業務上のアプリケーションでは基本的にDocker上での開発となっており、おおよそカバーできてそうな内容でしたが、あまりDocker自体をなんとかしようという発想がなくマルチステージビルドというものをしてなかったというのが気づきでした。ビルドイメージを下げられると色々と良さそうなので実践してみたいと思います。

DRY & 型安全にテスト用structを初期化しよう
スライド 動画

テスト用データを作成するためのtestfixtures,factory-goというツールとそれぞれの使いづらいところを補おうためにfixtoryというツールを作った話でした。今まであまりシンプルなデータを準備したテストしかしてなかったのですが、どのツールも良さげで使い方を覚えつつ活かして行きたいです。

HTTP クライアントを作ろうとして学ぶ、使いやすいインタフェー
スライド 動画

HTTPクライアントってシンプルそうで難しいなというのを改めて感じました。作るまでにどういう思考をするかの説明と実際にできたソースがあるのがありがたかったです。

Webアプリケーションにおける並行処理の難しさ
スライド 動画

なるほどと思いつつも消化不良な感じです。実際の要件も整理して合わせてコードもみていかないと理解が追いつかなさそうです。。。バッチとかで並行処理するのはシンプルですが、Webの処理で並行処理を用いるというケースが今までなく、もう少し資料を読み込んでみます。

GitホスティングにおけるGoとgRPCを用いた複製と分散のアプローチ
スライド 動画

こうなっているのか。。。という感想しか出ませんでした。情報が大分詰まって消化し切れていません。gRPCの動的proxyについては説明が丁寧で今後使う事もありそうなのでもう一度みておこうと思います。

Networking and Lightning TalksNetworking and Lightning Talks

Gormとの付き合い方 というタイトルでLTをさせていただきました。終わった後色々と指摘をいただけて本当にありがたかったのですが、次のLTもあり理解し切れぬまま進んでしまったのが惜しまれます。とりあえずsql.DBをそのまま使ってみては、SQLBoilerを使ってみてはという意見はいただけたのでそれは試そうと思うのですが、gormが設計思想的にどう微妙かをどなたか説明していただけると救われる方は多いのではと思います(自分がそうならねばとは思いつつ)。また終わった後にそもそも全件更新を止める設定であるBlockGlobalUpdateの存在を指摘いただけました。今回フィードバックをいただけて発表して非常によかったです。ネットワーキング（実質懇親会）も良い雰囲気で楽しめました。

懇親会

 さらにその後も主催の方含めた方とご一緒させていただきました。なかなか東京のカンファレンスだと同じ会社の方が集まったり知っている人会で何回もみている方と同席できたり、主催のSendai.goの方達も非常にフレンドリーであったりとても記帳な時間を過ごせました。あとでこれもうちょっと聞けばよかったと悔やまれました。

まとめ

話に関しては自分の中で完璧に消化できた！というのが半分くらいな気がしています。ただ去年がわからないな、今後使う事もなさそうだな、というのに対しわかるテーマわからないテーマがちょうど良い割合でもっと勉強したいなという気を掻き立てられました。

 

会自体についてはSendai.goの方達のこんなコロナ状況下でもなんとかやり切ろうという気概、来たからには全力でウェルカムするというホスタピリティが感じられて非常に素晴らしかったです。今後は東京以外でもできるという可能性を示せたのではないでしょうか？今回仙台を観光したいという気持ち半分（一泊し翌日は楽しみました)でしたが、思っていた以上にカンファレンスが楽しくて良い時間が過ごせたと思います。

 

皆様本当ありがとうございました！

SRE NEXT 2020 参加レポート

SRE NEXTというイベントに参加してきました。 https://sre-next.dev/

簡単にこれを書いた人のバックグラウンドを説明すると、スマートフォンアプリのバックエンドをGoで書いているプレイングマネージャーです。SREともインフラとも言えるレベルでSRE本も積んでしまっているのですが、会社にバックエンドのエンジニアが10名強でインフラも兼務しています。SREチームを作れる段階ではないのですが、個人としても会社としてもインフラなんとかしたいと思い今回参加してみました。

結果として参加してとても良かったです。SREの事がまだまだでも十分に楽しく、ためになる話がたくさんありました。強い会社が強いエピソードエピソードを披露するイベントと思いきや、すぐに使えそうなノウハウだったり初心者向けのセッションもあり良かったです。この記事では、私がみたセッションについて感想をまとめていきます。

一番最初のヨガのセッションの途中から参加し、セッションは全てA室のものを聞きました。これは聞きたいのの半分以上がA室だった事、最初にA室でそこそこいい席が取れてしまった事、途中他の部屋に写ろうとしたのですが満室だったり、また入り直すために並ぶ必要があり席を取り直すのが大変なため結局全部A室のを聞いてしまいました。

[A0] 分散アプリケーションの信頼性観測技術に関する研究

https://speakerdeck.com/yuukit/a-study-of-sre

SREの研究についての話でした。 話の中で出てきた地理も考慮したコンピューティングというのがダイナミックですごいなと思いました。 今回の主題ではないですが、超個体型データセンターというのも初めて聞いた言葉で、確かに今はAWSで言えば2リージョンあって そこで動かすのを当たり前になっていますが、それををも地域レベルでどんどん分割していって問題が起きないようにしていくのはすごいなと思います。

こんな浅い感想ではなく、もっと色々な事が述べられていていて濃厚なセッションでした。 またもう少し知識を得た上で見返したいと思います。

[A1] 40000 コンテナを動かす SRE チームに至るまでの道

https://techblog.yahoo.co.jp/entry/20191222793763/ NTT社でのSRE全般に関する網羅的な話でした。 PrivateなPaaSがある事も、40000コンテナある事も、それを安定させて動かすための監視体制やテストも 流石大手だ、、、という感想しかでません。ただ、40000コンテナのものを何年も運用させていたわけではなく、ここ二三年でコンテナ数が急激に伸びていたことは興味深かったです。そんな短期間でありつつもこれだけの仕組みを作れることは流石ですが。 大手はこうやっているというケースとして頭に入れておこうと思います。

[A2] パフォーマンスを最大化するための SRE のオンボーディング事例

https://speakerdeck.com/tkuchiki/sre-next-2020 SRE中途採用者に向けてのメルカリ社でのオンボードについてでした。 私としてなるほどなと思った所としては、 - オンコールが担当できるようになるのを目標とする - 技術知識だけでなく、ドメイン知識も重視する - ペアオペレーションやシャドウイングを用いて教えていく といった感じです。

余談ですが、シャドウイングというと医療系や語学学習では聞きますが、 エンジニアリングの文脈で聞いたのは初めてなように思います。今まで近い事はやってきたのですが、名前がついたように思います。オンコールも検索すると最初に出てくるのは医療系で、他の業種のノウハウを取り入れている感がありますね。

また、オンコールとされている正直自分が対応してしまう事が多く、これはちゃんとノウハウの伝搬ができていないなと再認識しました…。

[A3] freee のエンジニアは障害から何を学び、どう改善しているのか？

https://speakerdeck.com/manabusakai/what-do-freee-engineers-learn-and-improve-from-failures freee社が障害に対してどうやった向き合ってきたかと言う等身大かつ実直なセッションでした。 今の私の会社の規模がもし順調に伸びていったとしたら、同じような状況になることは目に見えていて 対策の必要性を実感させられました。会社の全サービスが2h止まるとか想像を絶します。 ちゃんとポストモーテム作るところから始まり、様々なアクションを起こされているのが非常に参考になりました。

今の自分の現場と照らし合わせると、失敗を共有して高あう文化ってまだできていないように思います。 参考にしつつ、自分の組織にあった障害対応フローを作っていきたいです。

[A4] 日経電子版SREチーム立ち上げ中

https://speakerdeck.com/osamunmun/ri-jing-dian-zi-ban-sretimuli-tishang-gezhong 日経電子版のSREについての話でした。 システム構成図が複数サービス、複数システム、インフラもクラウドやオンプレ、技術スタックもバラバラで苦労を窺い知れます。この中でSLI/SLOを設定しようとしてうまくいかなかったが、SREとしてシステムや組織をより良いものにできたし、そうなった上でもういちどSLI/SLOを考えてみようという内容で、SRE本の内容を理解しつつも時にはシンプルに考えたり現状に即した導入をしていこうというのが学びでした。

[A5] 急成長するPairsと共に変化・成長し続けてきたエウレカのSRE戦略

https://speakerdeck.com/kaneshin/how-to-keep-growing-sre-team-at-eureka エウレカ社のSREについてでした。 スライドがわかりやすくまとまっていて、参考になります。 現在に至るまでの流れ、SREチームのビジョン、ミッション、やっている事がクリアです。 SREの業務内容以上に、ここまでクリアに打ち出せているのが良いなと思います。

[A6] SREがセキュアなWebシステムを構築、維持するためにやれることはなにか

https://speakerdeck.com/isaoshimizu/what-can-sre-do-to-build-and-maintain-a-secure-web-system mixi社の家族アルバム みてねのSREの方が語るセキュリティについての話でした。 セキュリティに関連するSREConの発表の紹介から始まり、実践できそうな内容がチェックリストにできる粒度にまとまっていて非常に良かったです。これと照らし合わせて今のシステムやAWSの運用をチェックするところをまず始めたいと思います。 ポストモーテムに対する取り組みも良かったです。作成者を称賛する文化を作ったりであったりとか、SRE以外のメンバーも巻き込むであったりとか、見習いたい所がたくさんありました。

[A7] サイト信頼性エンジニアリングの原則

GoogleのStackdriver担当であり、私としてはGoのカンファレンスの方で拝見する事が多い@ymotongpooさんのセッションでした。 このセッション非常に良かったです。SREの基本事項や原則を具体例と共に説明されていて、自分自身SREに対して誤解していた事も分かったし、SREをよく知らないメンバーがSREを深く理解していく助けになるのではと思います。

資料は現状出ていなさそうなので、個人的に印象に残った部分をピックアップすると

  • GoogleのSREチームのマークにはspes consilim non estと書かれている
    • これはhope is not a strategyという意味
    • これ以上細かい説明はなかったように思うが、「願望は戦略にあらず。望んでいるだけでなく、proactiveに対処していこう」という解釈で正しいはず
  • 複雑性はコスト
    • 柔軟性よりも一貫性のほうが価値があることがある。例外はコストが高い
    • 避けられないケースもあるが、必要もなく言語を変える他複雑性をとっていく必要はない
    • 一貫性と単純性は大事
  • モニタリングは二つ以上のやり方で行う
    • ホワイトボックスは内部からのテスト。例えば /varz,NSMP
    • ブラックボックスは外部からのテスト。例えば Ping, HTTP, IP SLA
  • アラートに思いやりを！
    • SLO違反になる危険性がなければページしてはだめ
    • ページしない、って初めて聞いたけどpageは名詞である本とかのページとは別にto call a person using a loudspeaker (= an electric device for making sounds louder) in a public placeという意味があり、つまりページングとはアラートで呼び出すという事らしい
    • 呼び出しちゃいけない例として冗長構成のクラスタが落ちた、ディスク95%フルかつ直近で変化が軽微(1w前に94.5%とか）、対応しようがない障害とか
  • メールでは対応しない方がいい
    • 追跡できない
    • オーナー不在
    • 低SN比
    • 人間による外部的な用心に依存
  • エラーバジェットとは定めたSLOで許容される時間のこと
    • SLOは結果としてxx%でした、というのを見るための喪ではない
    • 落としていい時間はどれだけか？その落としていい時間で何をやるかに注視する
    • 戦略的に落とそうというアプローチができる
    • 落としていい時間にできるアプローチとして以下のようなものがある
      • メンテナンス・デプロイ
      • 耐障害性テスト
      • よりシンプルなアーキテクチャにする
    • 厳しいSLOは変更速度を遅くする
    • SLOがないと対応するかしないかの判断基準が曖昧になる
  • ポストモーテムの良い例と悪い例
    • 悪い例、nginxの間違った設定をあげた。エンジニアはもっと注意する。金曜にリリースをしない
    • 良い例、間違った設定のファイルがテストなしに上がった。それを防ぐための対応は〜〜
    • もっと注意するのもっとって曖昧。事実と明確な対応を記載する。
    • 具体的な対応の例としては以下
      • gracefulな退役
      • 差分による予防(20%以上の行変更)でない時のみ自動リリース

長くなりましたが、それだけ内容が詰まっていて自分の中に残る部分も多かったです。

[A8] Webサービスを1日10回デプロイするための取り組み

https://speakerdeck.com/fujiwara3/sre-next-2020 面白法人カヤックのSREに関しての発表でした。 まさに歴史の積み重ねと技術の結晶といった感じで、非常に楽しいセッションでした。 スライドにもしっかり書かれており、詳細は省くのですが、良いなと思ったプラクティスは以下のような感じです。

  • リリースログをgoogleカレンダーに投稿
  • githubの差分をsongmu/ghchで出力する
  • 祝前日のリリース禁止をリリースした後は対応できる人員を事前確保するというルールで防ぐ
  • circle ciのPerformance Planで遅い問題を一気に解決する
  • circle ciはverginiaで動いているのでイメージもそこに置く（でないと転送量が大変なことに）
  • エラー検知のアプローチ

自社でもこうやって仕組みを作っていきたいという気持ちが湧いてきました。

[A9] パネルディスカッション

パネルディスカッションでした。SRE本の訳者の方がいて、SRE本のプラクティスはGoogle他大規模だからワークするものと、今すぐに使えるプラクティスと両方ある。やれる所からやった方が良いという話をされたり、SREをやっていて良かった事としてGoogleではたらかれていた@tsekineさんが書いたコードは-10万行(それだけいらない設定を消せた）という話をされていたり、このセッションも非常に良かったです。

まとめ

さらっと書こうとしたらもうすでに2hこれを書いています。それほど密度の濃いイベントでした。次回は会社の誰かを連れてきたいです。インフラというのは技術だけでなく、組織の理解やメンバーの協力が必要であって、文化を作り上げていくものなんだというのをひしひしと感じました。

最後に運営のみなさま、発表者のみなさま非常に刺激的で楽しいイベントをありがとうございました！！！

DMM.go #1参加レポート

DMM.go #1に参加してきました。備忘録もかねて簡単にまとめます。

Cloud Nativeな時代に考えるmonorepo 松本 勇気

要約すると

  1. NCな時代にはいろんなものを使うk8s,CaaS,FaaS, Managed Serviceなど
  2. マイクロサービスにする。依存の管理が大変monorepoにする
  3. 賢いビルドツールが欲しい
  4. Bazelが良さそう。だが、学習コスト等辛いところも多い。

といった感じでした。

他でよく聞く話もあるものの言語化がクリアでわかりやすかったです。まだ自分の普段担当しているサービスはマイクロサービスに切るレベルではなさそうだけどアンテナは張っておこうと思いました。

PRACTICAL DISTRIBUTED TRACING 金 勝洙

マイクロサービスでそれぞれのサービスの性能を計測するための分散トレーシングの話。これをやるためには色々なツールが出ていて、ざっと上げただけでも

とあり、SDKもそれぞれ違って辛いのでうまく抽象化されているようでした。OpenCensusはそうやった分散トレースの収集ツールで、使いた等をされてました。
同じく今のシステムマイクロサービスでないため、いかしづらそうだけどいずれ。

VCR in Go：モック自動生成で楽しちゃう話 本田 雄亮

VCRという、実際の通信を利用してそこからモックを自動で生成してしまうという話でした。

vcrって知らなかったのですが、Video Cassette Recorderなのかというので驚きでした。取得したデータもCassetteなのが面白いし、通信を傍受してそのままモックにしてしまうというのがダイナミックで良いですね。

懇親会で少しお話ができて具体的に何をテストしているか伺えたのですが、ブラックボックス化しているサービスのリプレースで、テストに使われているようでした。外部サービスにかぎらず実際のAPIをそのままモックにできるというのは色々応用が利きそうです。外部のAPIの応答が非常に遅い場合もテストのストレスを下げそうですね。何かで試してみたいです。

チャット小説アプリ TELLER を支える GAE/Go 中村 智将

TELLERというサービスの1->10フェイズにおいて直面したビジネス的および技術的な課題についてどう対処してきたかという話でした。話が非常におもしろかったです。課題がよくあるもので共感できたり、それぞれの課題に対してちゃんと技術的なアプローチをしていていい仕事をしていて素晴らしかったです。Goあんま関係ないと言いつつも結構Goが絡んでいて良かったです。
良かった、参考になったポイントとして、

  • 依存関係をCIでチェックする、という発想がなくて参考になりました。これは今は若手のレビューでここでこのライブラリを読んじゃだめみたいなレビューを入れる事があって、ここがCIで弾けると良さそうですね。
  • アダルトを画像認識で弾くという話、全部人力でやるとコストが高く、全部機械認識だとまだ誤判定が厳しいというのがリアルでした。今はうまく両方用いているようです。単なる焼き芋がバイオレンスな画像判定されたというのがツボでした。
  • DIはwireを使われているそうです。良いと聞くので試したみたいところ。
  • Elasticsearchが学習コスト高くて、Algoliaを使ったが良い反面色々辛いところがあって、Elasticsearchに戻りたい気持ちがある、というのが技術選定の苦悩あるあるですね。Algoliaは知らなかったので参考になりました。
  • ランキングをRedisでというのはよく聞くのですが、Redisだけだと厳しい部分もあるのですね。
  • 権限周りの実装をどうするか

等々、全体を聞いていて感じるのは銀の弾丸ってないよなぁ…という感じです。

まとめ

半分がマイクロサービス絡み、半分がバラエティにとんで実践できそうなものといった感じでした。企業主催のGoイベントは企業のサービスに合わせた実践的な内容が多くて良いですね。ありがとうございました！

 

VimConf2019参加レポート

vimconfにいってきましたのでレポートします。今回が初参加でした。

vimに関してはビギナーなのですが、理解できない話も多かったものの面白い話が多く、雰囲気も非常に良かったです。一日vimにどっぷり浸かることができました。 

バックグラウンド 

vim歴は2年ほどになります。その頃にメインの言語がPHP->Goに移り、Goを書くのにvimがほどよくvimを使うようになりました。

なおエディタ歴はEclipse(Java)->秀丸(PHP)->Eclipse(PHP)->Sublime Text(PHP)->Vim(Go)といった感じです。

 

vimrcは300行程で、今日の話を聞くにおそらく全然使いこんでいない勢のはずです。

goをやり始めてからvimの話を聞くことも多く、vimあまり使い込んでいないけど面白いセッションもあるかも、ということで参加を決めました。

Vim Renaissance         Prabir Shrestha

今のvimの状況、その中でのvim-lspというプロダクト、そして今後という

話が語られました。

 

vimで次に来るrevolutionとして、

- ECMAScript/JavaScript interface for vim.

- WASM

の二つが語られていましたが、なぜこの二つが今後必要とされているかが今一理解できなかったのでまた見返します。

 

話も面白かったのですが、何より質疑応答パートが面白かったです。

vim-lspの感謝が伝えられたり、ルネッサンスと革命をスライドの中でどのような意図で入れたか聞かれたり、vimの本体で直したい所がきかれていて、それがmattnさんだったりと非常に盛んで有意義なFAQセッションでした。 

We can have nice things    Justin M. Keyes

nvimについてでした。nvimを使っているのは会場の三割ほどだそうです。

nvim自体をよく知らなかったため、コンセプト等々理解できました。

 

後半は正直ついていけなかったのですが、怒涛のセッションでした。

印象に残ったフレーズを以下にピックアップします。

 

Goal is not to replace vim

nvimはvimを置き換えたもののではないというのが、大事なコンセプトだそうです。

それだけ、vim本体が歴史的経緯で積み上げたものがあり、手が入れづらい所があるという事なのですね。

 

vimscript is unbelievably slow

2回ぐらい言っていました。遅いため、luaを活用しているようです。

 

No commits for 4 days. Is Neovim dead?

4日間コミットがないだけでneovimは終わったのか？と言われたそうです。非常に盛んに開発されているのですね。

 

Your Vim is Only for You         mopp

vimを使い始めてから自分用のvimにしていくまでが語られていました。わかりやすいセッションでした。

語られたテクニックとしては

- 起動時間を早くするためにlazy loadingを活用する

- Leaderをスペースにする

- よく使うものはmapping,時々使うものはcommand、それ以外はfunctionにする

- DRYルールを意識する

- vimrcが溢れてきたらプラグインに切り出す

といったもので、vimの基本的な挙動を抑えた後に活用しやすいものばかりでした。

 

dotfileも適度に読みやすそうなので、参考にします。

https://github.com/mopp/dotfiles/blob/master/.vimrc

 

起動に関しては私の環境ではtmuxとvimを利用して、vimを基本的に開きっぱなしにしているので１日に数回しか起動をしないです。

起動回数が多いという事はどのような使い方をされているのかという事が気になりました。他の方がどんな環境でvimを使っているのかも今後聞いてみたいところです。

 

Grown up from Vim User to Vim plugin developer side        IK

以下に自分がvimにはまっていって、今はコントリビュートまでできるようになったかという話でした。

徐々に強くなっていって、最後には人に力強く進められるようになるというのが凄いと思いましたし、アツい想いがひしひしと伝わるセッションでした。 

Usage and manipulation of the tag stack       daisuzu

なんとなくtagを使っていましたが、こんな動作原理なのですね。tab周りをやる事があれば見返します。

make test        m-nishi

testに関する話でした。ここもいずれやる時に参考にします。

My Vim life      gorilla0513

gorillaさんのセッションで、vimを使い始めてから今は色々なプラグインを作って、本や連載をされるまでの話でした。

一年でこれだけのアウトプットを出されている事に驚かされました。

語り口が優しく、素敵なセッションでした。

Using Vim at Work!    Danish Prakash

仕事でvimを使う際の色々な話をされていました。

マウスを使うという発想がなかったのですが、確かにペアプロとかする時に困りますよね。

後、visualizing 60000time faster than texturalということで、ビジュアル化するということも大事ですね。

Let's Play with Vanilla Vim      Hezby Muhammad

何も入れてない状態でのvimについての色々でした。最初はvimrcが30行ほどだったそうですが、その30行に何が書かれていたかは気になるので、後で見返します。 

13 Vim plugins I use every day           Tatsuhiro Ujihisa

様々なプラグインを使った実演でした。vimのなかでshellを使うという発想がなかったのでまず衝撃でした。このような使い方をされている方ってどれだけいるのでしょうか？もはやエディタを超越していますよね。その後も何をやられていたかが追いきれなかったので、ここは動画が出るのであればもう一度見返したいです。

My dark plugins development history ~ over 10 years ~       Shougo

今まで作られてきたプラグインの話でした。いつも利用させていただいていたのですが、世代があるのは知りませんでした。ここまで色々な経緯があったのですね。 

全体を通して

後半まとめが大雑把なのですが、正直聞いていて自分として情報過多で疲弊しました。日英で聞いた事も大きいかもしれません。あまりに疲労感があって懇親会は出ずに抜けてしまったのですが、次回は懇親会で楽しく話ができるぐらいに知識と余裕をつけて臨みたいです。

 

消化しきれていない部分は多々ありますが、それでも全体を通して非常に刺激のある楽しいカンファレンスでした！会自体も非常にしっかりされていて非常に良い環境でセッションに集中する事ができたのも良かったです。運営のみなさま、改めてありがとうございました！