Yuigo・ん・・・湿っぽい

モルック、システムエンジニア、その他趣味。大学生のころから使っているので、昔の記事は恥ずかしいし今の思想とは異なっていることが多いです。

(自分用メモ)勉強会メモ WEBエンジニア勉強会 #WEM14

サムネ

イベントページ

何故マイクロサービスにするんだっけ? (スポンサーセッション)

何故マイクロサービスにするんだっけ? #WEM14 / Why Microservices? - Speaker Deck

マイクロサービス間の通信はHTTPメッセージングが主、「境界づけられたコンテキストによる、疎結合なサービス志向アーキテクチャ

疎結合が一番重要。あるサービスに変更があっても、別のサービスには影響がないことを目指す。マイクロサービスにすれば自ずと疎結合になるわけではないので注意。

マイクロサービスにすることで頻繁にデプロイ・改善することができる。どんどんブラッシュアップして結果利益や価値を生み出したい。モノリスだと変更に対して、変更そのものに加えて影響調査に時間をかけることになる。またモノリスだと軽微な変更についてもサーバーをストップする必要に迫られる。

つまり、頻繁な変更が必要でなければマイクロサービスである必要はない。

マイクロサービスはサービスごとに言語やFWが選択できるのは理論的な話だが、実際はメンテに関するコストが高くなるので非推奨。また障害は起こりやすくなる(99.99% * 99.99% ...。さらにネットワークの接点が多くなるので障害点が増加する)。もちろん技術コストも高いし、クラウドインフラ費用や人件費についても増加すると考えられる。

疎結合にする失敗すると「分散モノリス」という状態になる。ベストプラクティスはまだ成熟していないのでは。まずは、モノリス疎結合に作ること、テストを書くこと(自動テストは必須)から始めるとよいのでは。

失敗例から知るサーバレス ~ APIGateway Lambda編 ~ (10分)

失敗から知るサーバレス

サーバーレスで失敗した話を紹介

バックエンドをAPI Gateway、Lambdaで作る

Payloadの上限で死んだ

10MBを超える画像でエラーになった。10MB以内の画像をアップロードしたがここでもエラー。API GatewayのPayloadとLambdaのPayloadの上限を超えないように注意しなくてはならない。圧縮するとかフロントから直接S3にアップロードするとかで回避しなくてはならない

タイムアウト制約

Lambdaのタイムアウトを起こしたパターン。最大は900秒なので伸ばしたところ、次はAPI Gatewayタイムアウトが発生。API Gatewayは最大29秒なので、ここまでに返さないと行けない。重い処理はSQSを使うとか、LambdaからLambdaを呼ぶなどで回避する。

サーバーレスは手軽だがサーバーレスのツールや技術に精通していないとハマりどころが多い。

愛されるダッシュボードの作り方 (10分)

愛されるダッシュボードの作り方

あんまりダッシュボードを眺める業務は多くないなあ(backlogとかならある)

ダッシュボードを構成する要素とどう作るか

ダッシュボードは結局使われないということが起こりがち。理由としては:

  • 実際に見たいデータではない
  • 可視化の方法が間違ってる(グラフの種類、平均と分布を間違える)

なので、正しいデータと正しい可視化を考える必要がある。

正しいデータを導くには、イテレーションが必要。ヒアリングして作ってみて、それが嬉しいかフィードバックをもらい…という繰り返し。実際に使う人・見る人の意見が重要になるので、コミュニケーションが円滑かつ素早くできるかも鍵になる。

なるべく作り直しの回数を少なくしたい。複雑な結果やクエリを取るには…ということで今回Jupyterを使ってみた。ローカルでも使えるが、「JupyterHub」を使うと複数人での利用が簡単になり、結果やJupyterファイルを共有することができる。また、利用者にひな形を配ることでダッシュボードの出力デモを作成することができる。JupyterHubのみでイテレーションを完結することが可能になった。

アジャイル好きのウォーターフォール (10分)

アジャイル好きのウォーターフォールとの付き合い方

ウォーターフォールを批判したいわけではない(わかる)

フリーランスだが、今の現場が簡単な要件なので、すぐに動くもの作ったほうがいいのでは?と思ってしまう

同じことをやっていると飽きが来てしまう、ただWFなので受け入れなければならない

ということで設計工程で実装を挟み込むことにしてみた。例えばDB設計書を書くのは苦痛。Railsマイグレーションファイルを書きたい!と思うので、SchemaSpyというツールでER図やテーブル仕様書を生成してみた。DockerイメージやRails用オプションがあるので今回の要望に適していると判断。これを用いてリバースエンジニアリングしてDB設計書を作成するデモを見せてもらいましたがかなり優秀ですね…

これによって、DBのマイグレーションコードが設計工程ができ、ドキュメントと実装の整合性が取れ、HTMLなのでGitで差分管理できる、など恩恵があった。

テスト仕様書については、RSPECというツールでテスト項目だけを記述した。またPICTというツールでテストケースを生成し、RSPECと組み合わせた。

という感じで、辛いと思っている作業を楽しくすることができた。三大美徳を最大限に活かす。

MDX-Deck v3 と Code-Surfer v3 (10分)

mdx-deck v3 and code-surfer v3

簡単にMarkdownでスライドが作れるツール。最近でも進化して、現在ページ数の表示、

ソースコードの表示についてはかなり便利なので、Diffの表示やハイライトもある

Opt + Pでカンペが表示できる、自分の画面はアウトライン表示、というPowerPointでおなじみのことができるようになる

GAEによるPythonWEBアプリケーションの高速開発 (10分)

GAEによるPythonWEBアプリケーションの高速開発

Django、有名なのはインスタグラムとかconnpassとか

Google App EngineはPaaS。Heroku的なものと捉えてOK。環境が2種類あり、Standard環境は制限がある

Nginxの設定などが省略される

yamlで構成ファイルを書く。ランタイムとかルーティングとか

gunicornが最初から入っているのでDjangoには便利

デプロイをすると自動でSSLつきのドメインが振られる、ありがたい

デプロイが遅いのが難点、そして価格がちょっと高い

GAE知らなかったのでPaaSを使う時の選択肢にはなりそう

機械学習の論文を読む

(すっごい面白かったのですがスライドリンクが見つからず…)

RecSys: 推薦システムについての国際会議・トップカンファレンス、ペーパーを見てみると面白そうなのが(意外と)ある

推薦システムについてのCreepiness(不気味さ)について、その人にからしてシステムに信頼感を置けるか?という指標や基準は時代や主観によって変わってしまう。Creepinessを分析して定量的にしようと試みた。感情を測る尺度を用いて数値化し、ユーザーが推薦システムを使った時の感情を分析しようとしたが、やはり複雑な結果が出てはっきりとした結論は出なかった。

ユーザーとシステムのどのような特徴がCreepinessを与えるか。人の性格を評価する指標を使って被験者の性格を評価してみる。やはり明確な特徴は出なかったが、「社会的信用がある人はCreepinessへの耐性がある」などの特徴らしきものが出た。「合理主義だとCreepinessへの耐性がない」とか。

推薦システムの特徴とCreepinessの関係を調べる。異なるドメインとRS(感情を測る尺度)の特徴をユーザーを使った調査をおこなった。比較的Health(健康)に対するCreepinessは高くなりがちだった。センシティブな話題だから?

Creepinessな推薦はユーザーにどのような影響を与えたか。推薦システムを体験した後でどのような心境の変化が被験者にあったか調べる(コンテンツやプラットフォームへの印象、推薦システムへの信頼度など)。推薦されたブランドやプラットフォームへの印象は悪くなるが、推薦システムへの信頼度が落ちることがなかった。体験後はシステムの透明性や、システムを自分で制御できることを求める感情になるようになった。

意外と普段の業務に活かせるような論文もあるので探してみてください

感想

テーマの縛りが少ないLT会は思わぬ収穫、興味への第1歩が見つかるのでとても有益だと思います。特にダッシュボードについては今後いろんなサービスのそれを見るたびに注目しちゃうかも。いろんな人も仕事がここに詰まってるんだなあ…とか