「Go言語によるWebアプリケーション開発」5章分散システムと柔軟なデータの処理

5章は分散システムと柔軟なデータの処理として、TwitterのストリーミングAPIを使った検索と保存処理を行なっています。

この章では、NoSQLのMongoDBやTwitterAPIやキューサービスの利用といままでやったことがなかった内容があり、読む前から楽しみにしていました。

そして、いまだにあまり理解できていない状態で書いています。

理由としては、ソースで並列処理が多数あったり、Twitter（個人的にはそれほど利用していない）の利用がネックになっていると思います。

並列処理のソースからなぜこのように書く必要があるのか。という理解ができないため、ただ写経して動作するのを見る感じになっています。

経験からソースを書いていれば、どこかでブレイクスルーがあり、突然理解できるということが多く、とにかく書いて覚えることがいいと思います。また実際のシステムに利用してみるのがいいですね。

実際のシステムに活用すれば、いやが応にも工夫をするので、大体使えるようになっています。

またNoSQLといういままで使ったことがないデータベースやキューサービスという個人的に馴染みのないシステムを使っているため理解まで進むのが大変だからだと思います。

こういうのが作れるのか。というぐらいの認識で進めれば本当に使うようになったときに調べればいいと思いますが、今回に関してはせっかくいままで触れてこなかった仕組みとの出会いを歓迎し、理解したいので、数回読み直しています。

MongoDBというデータベースがあることは知っていました。ただ利用したことがなく、NoSQLといわれる分野のDBも自分で組んできたシステムにはありませんでした。

MemcacheやElasticSearchなど使ったことはありますが、ユースケースが決まっており大体マニュアル通りに書けば、求める仕組みになっていたので、自分で読み書きするシステムについては構築したことがありません。

そのためRDS向きでないユースケースの際にも、NoSQLの特性が理解できず踏み込めていませんでした。RDSでやっていた監視の仕組みでコネクションに困らされ、別のアプリーチを実施しましたが、NoSQLにできたらきっと違うアプローチができたと思います。その時の自分の能力ではあれが限界だったと思います。

基本的にシステムでミドルウェアを無理やり使う必要はないので、必要なときに使えばいいと思っていますが、必要なときに選択肢にできないのはもったいないので、触りぐらいは理解しておきたいです。

スキーマレスということはよく言われているな。スキーマに決まりがないということはJoinとかないのかな。どういうスキーマでいれると楽なのかな。まぁ、最初は必要な情報をとにかくいれてみて、検索してみることかな。

という適当な感じで触っていくしかないと思っています。ある程度理解してからでないと人の説明が入ってこないので、苦労してみるつもりです。

GUIとかあるのかな。ほしいな。

NSQというBit.lyが開発と保守をしているメッセージキューを利用しています。

AWS SQSと同じと思っていますが、SQSも使ったことがないので、自分が理解しているシステムの内容を書いてみます。（間違っている可能性は高いです）

キューとして実行してほしい内容をためておくことができるサービスで、分散システムやマイクロサービスにしやすくする仕組みだと思っています。

キューに保存すれば、処理自体は終了できるためフロントエンドの見た目上のレスポンスを上げることができ、余計なエラー処理を記述しなくてもよくなると思っています。

処理自体はバックエンド等で順次消化される仕組みになり、一つのサーバーに依存しなくなるため実装の柔軟性が上がる仕組みだと思います。

リアルタイム性は少し劣りますが、バックエンドの処理で問題がない部分に関して使うのがいいと思っています。

また本書を読んでいるとNSQはスケーラビリティを意識した設計になっている。とのことです。

順次処理できるということは、できる分だけ処理をするから過負荷を抑えることができるとも捉えることができますね。

最近は、細かいシステムで作ることで疎結合にできるのでオススメの仕組みなんでしょうね。あまり考慮にいれたことはないです。

だってミドルウェアが一つ増えるということは管理が大変になると思うので、必要にスピードを求められない限り一つの仕組みで書いてしまいそうです。

そういう意味で個人的にはAWS SQSのようなクラウドサービスを利用すると思います。

使ってみたいシステムだったため、今回書いてみて動作したのは有り難かったです。

並列処理が書かれたソースを見ると、go言語の面白さや便利さを認識します。WEBサービスとしては細かいアプリケーションの組み合わせが重要に思えてきます。

すこし規模の大きなシステムを組んでいますが、ほかの言語のほうがフレームワークが充実していると思えることが多く、go言語で規模の大きなシステムを組むのは少し懸念しています。

まぁ、go言語が悪いわけでなく使うエンジニアの理解度が原因なんですが、仕組み化できていないため難しいですね。

やっぱりフレームワークは本当にいろんなことをしてくれていると思います。作っている人たちはすごいですね。

個人的には、go言語は書いていて楽しいですね。オープンソースのためソースを読めばできることが広がるし、型がある言語が好きになりつつあるので書いていて楽しいです。もっと広がって欲しいです。

次は「REST形式でデータや機能を公開する」です。

kazu22002の技術覚書