Takuya UedaSouzoh, Inc. (affiliated by Mercari, Inc.) - Go Engineer
Takuya UedaSouzoh, Inc. (affiliated by Mercari, Inc.) - Go Engineer
こんにちは。私はSergey Kamardin(セルゲイ・カマルディン)です。Mail.Ru(ロシアの電子メールサービス会社)で開発者をしています。 この記事では、どのように私がGoを使って高負荷対応のWebSocketサーバを開発したかについて説明したいと思っています。 パフォーマンス最適化のアイデアやテクニックを通じて、WebSocketの知識はあるもののGoについてはほとんど知らないという方のお役に立てれば幸いです。 1. はじめに まずは開発に至った経緯について、どうして私たちがこのサーバを必要としたのかを説明しておきましょう。 Mail.Ruには多くのステートフルなシステムがあります。ユーザのeメール保存もその1つです。システム内、およびシステムイベントの状態変更を追跡する方法にはいくつかの種類がありますが、それらは主に状態変更に関するシステム通知、または周期的なシステムのポーリ
Golangのerrorにはスタックトレース情報はない.基本は必要ないと思うし困ったこともない.一方で新しくプロジェクトに入りかつコードベースに慣れてない場合はどこが問題かアタリをつけるためにあっても良いとも思う.pkg/errorsを使ってるならそれはすぐに実現できる. pkg/errorsの基本的な考え方についてなどは GoCon 2016 springの後に "Golangのエラー処理とpkg/error"にまとめた(作者のDaveのブログ記事は "Don’t just check errors, handle them gracefully").ここで強調して書いたのはちゃんとエラーをアノテートする(何をしてそのエラーが発生したかの状況を付加する)ことである.特に外部のパッケージとやり取りする場合,つまりまともなエラーメッセージが返ってこないかもしれない場合,pkg/errorsの
記事中に間違いがありました。数倍も速くはなりませんでした。確か 1.0X ~ 1.1 倍程度の高速化は得られましたがびっくりするほどの物ではありませんでした。すみません。 そろそろ Go1.7 がリリースされるそうですが、皆さん如何お過ごしですか。Go 界隈の波平こと mattn ですこんにちわ。バカモー(略 Go1.7 ではコンパイラの最適化が行われ、ビルド速度がかなり短縮される様になりました。毎日ビルドしてる僕としては非常に嬉しい機能改善ですね。 さてとてもキャッチ―なタイトルで釣ってしまった訳ですが、気にしたら負けなのでどんどん話を進めます。 var t [256]byte func f(b *[16]byte) { for i, v := range b { b[i] = t[v] } } 例えばこのコードを見て下さい。このコードはココから拝借しました。issue の内容はスコー
Go でアプリケーションを作ると、そのまま他になにもなくとも実行できるバイナリが出来あがります。この特性によりデプロイが大変楽です。 このような特性があるので、 Go を使う場合 Docker のようなオーケストレーションツールを使わなくても多くのサーバーにアプリをデプロイしていくことも可能かと思われますが、そこはまあ Docker という巨人に乗っておくと楽なことが多いです。具体的には swarm と docker-compose が便利なので Docker 上で実行したい。 ここで問題となってくるのが何も考えずに Docker イメージを作るとイメージサイズが膨れあがってしまってシングルバイナリによる手軽さなどが損なわれてしまうという点です。 たとえば golang:alpine のような比較的小さいイメージを使ってもファイルサイズはバイナリサイズ + 300MB ほどにもなってしまい
僕がプログラミング言語「Go言語」を知り、使い始めてからそろそろ7年目に入ろうとしています。 当初 Google が作っているという鳴り物があった為、色々なメディアに取り上げられ色々な方がブログ等でGo言語を紹介し、色々な意見でGo言語が語られました。大抵の場合、プログラミング言語とは始めはチヤホヤと取り出され、落ち着いてからが本当の人気を表すという傾向にあります。皆さんもそう思っていたかもしれませんし、僕もそう思っていたと思います。 僕がGo言語を触りだした頃、まだ色々と足りない部分がありました。Linux で動いている多くの機能が Windows では未実装になっていました。しかしそんなGo言語であっても高速なビルドと実行速度で僕の好奇心を揺さぶるには十分な物でした。 その後、僕はGo言語にパッチを送る様になりました。その内幾らかはマージされました。現時点ではコアのリポジトリで79個の
Reactive Messaging Patterns読書会のなかで、「マイクロサービスとAkkaとGo」な面白い話題が出たので代表でまとめる試みエントリです。(結構、色々な話題に飛んでいるので難度高い。) まとめ方としては、会話ログを転記して、最後にまとめる形をとっています。また、議論と私の考えが混ざらないように所感は分けておきます。 ddd-cqrs-es.connpass.com TL;DR 要素技術(どんな言語使うとか、どんなアーキテクチャにするとか)の前に、組織やプロダクトの性格を考えて戦略を決めましょう。 そして、その中で最適と思われる戦術をとれるような要素技術を採用しましょう。 Akka良いよ。 ログ(一部抜粋) Slackからの引用のためテキストベースです。 事の始まりは、荒木さん(以下、 @applideveloper )の発言でした。 (この記事絡みですね。 集合知で各
Go書いててなんとなく見えてきた Goでやっちゃいけないパターン WAF導入してらくらくWebアプリ WAF自体が現在群雄割拠状態。 WAF毎にハンドラインターフェースが違うので既存コードつなぐにはラッパーが必要。 どのWAFもLL言語に比べるとまだまだフィーチャーの網羅範囲が狭い。 なのでもちろんLL言語ほど楽には書けないことが多い。 リフレクション使いまくりでトータル性能はLL言語並みに遅いのもある。 Go1.7のcontextパッケージの導入で標準のHTTPハンドラが復権する可能性があり更に荒れる予想。 追記: 楽できるのを期待してWAFを導入するの「やっちゃいけない」とまでは言い過ぎだったかもしれないけれど例のsqlでPrepareを正しく使えていないで性能出なかった件とか、当面WAFを使うなら自分で概ね中身を理解して使う覚悟が必要。 構造体メソッドにロジックを詰め込む Goの思想
FINAL FANTASY Record Keeper用に作ったツールのGolang実装についていろいろ。Read less
さて、このタイトル、かなり挑発的ですよね。それは認めます。もう少し説明すると、私は大胆なタイトルが好きなのです。人の注意を引くことができますからね。とにかく、この記事では、Goがひどい設計の言語(実際、本当に全て台無しになります)だということを証明していこうと思います。私は既に数カ月間Goで遊んでいますし、たしか6月のいつだったかに初めてHello, Worldを走らせてもみました。私は数学がそんなに得意ではありませんが、あれから既に4カ月経っていますし、 Github 上のパッケージもいくつか手に入れました。言うまでもありませんが、私は仕事でGoを使ったことは全くないので、”コードサポート”や”デプロイ”やそのあたりに関する私の意見は話半分で読んでくださいね。 私はGoが大好きです。使ってみて大好きになりました。慣用表現を理解したり、ジェネリクスがないことや、おかしなエラーハンドリングや
連載目次 その1 〜インストール編〜 その2 〜画像の表示とイベント〜 その3 〜タッチイベントとライフサイクル〜 その4 〜音の再生とセンサー〜(予定) その5 〜簡単なゲームをつくってGoogle Play Storeに公開しよう〜(予定) はじめに @tenntennです。 もうすぐGoのバージョン1.5がリリースされる予定ですが, みなさまはどの機能に注目しているでしょうか? コンカレントGCだったりshared libraryが作れるようになったりと,Go 1.5は非常に楽しみです。 その中でも私は,Go 1.4で入ったGo Mobileのアップデートに注目しています。 Go Mobileは,Goを使ってモバイルアプリを書くためのツール類を提供するプロジェクトです。 Go 1.5では,iOS向けのアプリがビルドできるようになったり,Androidのサポートが強化されるようです。
Go1.5はクロスコンパイルがより簡単 Cross compilation just got a whole lot better in Go 1.5 | Dave Cheney Go 1.5: Cross compilation — Medium Go言語の良さの一つにあらゆるOS/Archに対するクロスコンパイルがとても簡単に行えることが挙げられる.今まで(Go1.4以前)も十分に便利だったがGo 1.5ではさらに良くなる. 今までの問題を敢えて挙げるとターゲットとするプラットフォーム向けのビルドtool-chain準備する必要があるのが煩雑であった(cf. Go のクロスコンパイル環境構築 - Qiita) $ cd $(go env GOROOT)/src $ GOOS=${TARGET_OS} GOARCH=${TARGET_ARCH} ./make.bash --no-clea
ここでは、私がたどりついた最善のやり方を紹介しましょう。個人的に過去数年にわたって大量のGoコードと付き合ってきた経験から集めたものです。これらは全て非常にスケーラビリティがあると思っています。私が、スケールする、と言うときは次のような意味があります。 アプリケーションが求める環境は、アジャイル環境の中で変化していきます。開発の3、4か月後に、全てをリファクタリングする必要が出てくるなど、考えたくもないはずです。新しい機能は簡単に追加できなくては意味がありません。 あなたのアプリケーションは多くの人々によって開発されます。可読性が高く、維持しやすいものでなくてはなりません。 あなたのアプリケーションは大勢の人々に使われます。バグは容易に特定でき、修正できなくてはなりません。 長期的にみるとこれらのことが重要になる、ということを私は今までに学んできました。小さなことであっても、多数に影響しま
Go言語のDependency/Vendoringは長く批判の的になってきた(cf. “0x74696d | go get considered harmful”, HN).Go1.5からは実験的にVendoringの機能が入り,サードパーティからはDave Chaney氏を中心としてgbというプロジェクベースのビルドツールが登場している.なぜこれらのリリースやツールが登場したのか?それらはどのように問題を解決しようとしているのか?をつらつらと書いてみる. Dependencyの問題 最初にGo言語におけるDependecy(依存解決)の問題についてまとめる.Go言語のDependencyで問題なのはビルドの再現性が保証できないこと.この原因はimport文にある. Go言語で外部パッケージを利用したいときはimport文を使ってソースコード内にそれを記述する.このimport文は2通りの
GCCのメーリングリストに、「現状GCJ(Javaコンパイラ)はもうメンテナンスモードになっており、OpenJDKのような活発に活動しているコミュあるし、GCCがデフォルトでサポートする言語として維持して行くにも負荷がかかっている。GCJをもうやめてGoをやらないか」と言う提案があったようだ(マイナビニュース)。 新しいプログラミング言語が出て間もない頃は言語の仕様も比較的小さいし、将来モノになるのかどうか不安がつきまといますが、とは言えキャッチアップもしやすいし、さもありなんと思ってしまうところだが。 /.Jer諸氏でGCJやめてGoにするとの提案について、見解を語ってみようではありませんか。
下記質問にそれぞれ50文字以内を目安に簡単に説明すること。 パッケージ内に定義した関数を外部に公開するにはどうすれば良いか? 非同期に処理を行う為の命令は? 関数を抜けた際に処理を実行するにはどうするか? goroutineの同時実行数を変更するにはどうするか? コンパイラやリンカが8g/6g/5g、8l/6l/5lという名前になっている理由は? Goのガベージコレクションの実装は一般的に何と呼ばれている類か? レシーバがnilの場合にメソッドを呼び出すと何が起きるか? 可変個引数はどの様に定義するか? 関数内で定義されるローカル変数のアドレスを戻り値として外部から参照するとどうなるか? interfaceとstructの違いは何か? panicを補足して強制終了させない為にはどうするか? 答え パッケージ内に定義した関数を外部に公開するにはどうすれば良いか? 関数名の先頭を大文字にします
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く