re:annkara

日々学んだことを書き留めておく。

JJUG CCC 2018 Fallに参加してきました。

先週土曜日に開催されたJJUG CCC 2018 Fallに参加してきましたので参加したセッションの簡単なまとめです。 セッション資料などは以下にまとめて頂いております。誠に感謝です。

github.com

思考停止しないアーキテクチャ設計

@kawashimaさんのセッションで、到着した時にはすでに会場は満席で、後ろの方で座りながらセッションを聞いていたのでスライドが見れず、ほとんど覚えていないのが正直なところです。。。
ただ、スライドの内容が非常に充実しているので、スライドだけを見てもかなり参考になると思いました。

以下はスライドを見て自分なりの解釈と気になった部分のメモです。

anond.hatelabo.jp

参考文献が三冊ほど紹介されているので、このスライドを元に目を通したいなと思います。

複雑なドメインに泥臭く立ち向かう

株式会社エス・エム・エスさんのスポンサーセッションです。
複雑なドメインとあってDDDの話かなと思ったのですがそうではなくて、エス・エム・エスさんのビジネスの土台となる医療・介護分野の複雑な法制度を例に、チームにおいてどのようにアプリケーションを設計・開発していくかというお話でした。

私も生命保険分野で業務系アプリケーションの開発をしていた時期もあるので、保険の制度が非常に複雑でどうやって実装するんだ??といった経験があり非常に共感できるセッションでした。
実装の対象領域(ドメイン)に対する学習は非常に重要で、そのドメインの知識を業務知識と言ったりするのですが、必要な知識というのは非常に膨大であったりします。ただ、その中でも本当に理解しなければならないコアな知識というのは存在しており、それをセッションの中では一本道を見つけると表現しているのかなぁと思いました。

コアな部分を見つけ、実際のコードに落として行く際にも、ホワイトボードを利用してチーム員で徹底して議論しながら知識を深めて実装していく進め方はチーム員で知識を共有しながら実装を進めて行くことができるので非常に良いなと感じました。

またそういう開発を進めていくために、チーム員を少数にしたりレイアウトも工夫していたりで、エンジニアが開発を進めやすい環境を整えているのは非常に好印象でした。

Deep dive Into instanceof

株式会社スマートニュースさんのスポンサーセッションでした。 Javaのinstaceofを利用したコードを何故避けなければならないのか、設計上の観点からではなく、性能面からJavaの内部実装を紐解きながら検証するという内容のセッションでした。

Javaの内部実装について全く明るくないので、セッションの全てを理解できたわけではないのですが、継承を利用していた場合には継承関係を順番に辿っていくため、深い継承関係がある場合にはその分遅くなり、インターフェースを利用していた場合には初回は線形探索を行うものの、結果をキャッシュするため、次回からは素早く動作するという理解をしました。

結局は設計においても性能面においても、単なるアプリケーションレイヤにおいてはinstanceofを利用することは避けるべきだなと思いました。

秒間 200,000 Req/sec をさばく広告入札システムを支えるパフォーマンスチューニング術

ウルシステムズ株式会社さんのスポンサーセッションです。
ソネット・メディア・ネットワークス株式会社さんのLogicadという広告配信プラットフォームのパフォーマンスチューニングについてお話されていました。

広告プラットホーム系のシステムのお話を聞くたびに処理件数であったり、応答時間のシビアさだったり本当にリアルタイム処理が必須になるシステムを開発・運用している人たちは凄いなといつも思います。

今回のセッションですと100ミリ秒(0.1秒)以内でリクエストの受付、処理、レスポンスを返さなければならず、要求される処理性能が非常にシビアです。

ただネットワークのレイテンシというものは距離に比例して伸びていくでしょうし、今現状のどんな技術を用いても光の速度を超えることはできないことを考えると、リクエストを受け付けてからレスポンスを返すまでの処理をどうにかして早くするしかない。

サーバの観点から考えると、スケールアップ戦略(ハードウェア性能の向上)とスケールアウト戦略(サーバの台数を増やす)で対応することは可能ですが、リソース調達コストを無視することはできず、無限にスケールアップ・スケールアウトすることはできません。

なのでアプリケーションの性能を向上させることが必須となり、そのためにはどこがボトルネックとなっているのかを把握することがまず重要です。

ボトルネックの可視化のために、perf + perf-map-agent + FlameGraphというツールを組み合わせてフレームグラフでアプリケーションコードの性能を可視化しているとのこと。 perfとFlameGraphについては知っていたのですが、その結果をフレームグラフで表示することができるperf-map-agentはこの時初めて知りました。

セッション中でも述べられていましたが、パフォーマンスのボトルネックとなる部分はアプリケーションだけではなくて、例えばWebサーバだったりDBだったりとどこにでも発生しうるので、システム全体の把握とどこがネックになっているのかを可視化することは非常に重要だと思いました。

最後に

最初にJJUG CCCに参加したのはちょうど2年前の2016 Fallでした。
恐らく私が初めて参加した技術カンファレンスで、Webエンジニアとして全くの初心者だった頃もあり、雰囲気に呑まれていたのを覚えています。
この2年間で様々な技術に触れ、エンジニアとして知っていること・出来ることというのが増えたなというのは、今回改めて参加してみて実感しました。

ただあの時感じたような技術やコミュニティに対する新鮮な気持ちというのは大分薄れてしまった気がします。
それは自分が知っていることが増えたことで、単に技術というものに慣れてしまっただけのように思えます。
その慣れは最近、自分が感じている停滞感に繋がっていると、このブログを書いていてハッキリと自覚しました。

技術に慣れるのではなく、技術や知識を深め、使いこなし、また新しい何かを作り出していくこと。
2年前の自分はそんなエンジニアになりたかったのだと思い出しました。

改めて自分の目標を再認識することができたことは本当に良かったです。 今後も引き続き参加していきたいと思います。