こんにちは!
好きなスシローは五反田店なバックエンドエンジニアのりほやん( @rllllho) です。
9/6,7,8に開催されたbuilderscon tokyo 2018へ参加しました。
カンファレンスで印象に残ったセッションをいくつかご紹介します。
buildersconとは
公式サイトにはbuildersconについて下記のように説明されています。
buildersconは「知らなかった、を聞く」をテーマとした技術を愛する全てのギーク達のお祭りです。buildersconではトークに関して技術的な制約はありません、特定のプログラミング言語や技術スタックによるくくりも設けません。 必要なのは技術者達に刺激を与えワクワクさせてくれるアイデアのみです。 あなたが実装したクレイジーなハックを見せて下さい。あなたの好きな言語のディープな知識をシェアしてください。あなたの直面した様々な問題と、それをどう解決したかを教えてください。未来技術のような未知の領域について教えてください。
記述の通り、プログラミング言語に特化したカンファレンスではなく包括的に様々な技術を扱っているカンファレンスです。
印象に残ったセッション
知らなかった時に困るWebサービスのセキュリティ対策
tnmtさんによるカラーミーショップで実際に発生したセキュリティインシデントの実例を元に、どのような攻撃が仕掛けられたのか、どのような対処・再発防止を行ったかについてのお話でした。
上記インシデントの検知は、不正なファイルが置かれたことを検知したのではなく不正なファイルが実行されたことにより発生した負荷アラートがきっかけで発覚したそうです。
またデータベース関連のログが不足しており、データベースへアクセスされた痕跡はあったものの何件抜かれたかなどがわからない状況だったそうです。
インシデントを受けセキュリティ新体制の見直し、WAF、OSコマンドの実行ログ、クエリログを残すなどの対応を行なっているそうです。
webアプリケーションに携わっている身として、セキュリティの問題は絶対避けては通れない問題です。 実際に起こってしまったインシデントに対しての対応や経験など実体験を聞くことができ、とても勉強になりました。
「Webとは何か?」あるいは「WebをWebたらしめるものは何か?」
Jxckさんによるwebのこれまでの歴史、いまのwebの役割とは何なのか、これからのwebはどうなっていくのかというお話でした。 ティム・バーナーズ=リーが構想した最初のwebはHypermedia Systemとしてのwebでした。 JavaScriptやiframeなどを使用できるようになりwebによってできることが増え、webはHypemedia Systemからアプリケーションシステムへと役割が変わっていきました。 さらに現在ではwebからデバイスに接続できるようにもなり、Operation System化しているとのことでした。
webはセキュリティモデルと共に進化しているという話が印象的でした。
Ajaxの登場によりJavaScriptがブラウザの意図しない情報を通信できるようになったため、セキュリティモデルとしてoriginが導入され、このoriginというセキュリティモデルがあるおかげでAjaxを正当化できwebのアプリケーション化が進んだそうです。
そのためOS化しようとしている現在のwebのセキュリティモデルであるPermissionの必要性についてお話しされていました。
セキュリティモデルをどのように変化させて策定するかがwebの進化にとても重要であるという話がとても面白かったっです。
ソーシャルゲームが高負荷に陥っているとき、何が起こっているのか
takihitoさんによるゲームの開発や運用の体制についてのお話でした。 実際にゲームを運用する上で発生した高負荷による障害とその対応について4つ紹介されました。
- アプリケーションサーバーに対する高負荷検証は行なってはいたが、ログサーバーが盲点となっておりボトルネックになってしまった話
- リリース後にサーバーの負荷が異常に高くなっており確認したところ、Redisのkeysコマンドがアプリケーションで使用されており高負荷になってしまっていた話
- 大規模な流入施策を行うために検証を行なってはいたが、アプリ申請後に重たいリクエストをアプリから頻繁に叩かれていることに気づきAPIを軽量に研ぎ澄ました話
- ガチャによる高負荷によりDBが詰まり緊急メンテナンス、DBのチューニングやアプリケーションコードの修正を行なっても収まらず最終的にはテーブルの設計変更を行った話
ゲームならではの急激な高負荷についてのお話はとても興味深かったです。
高負荷対策のお話の中で、レプリケーション遅延なども考慮しなければいけないためアプリケーションのスケールアップよりDB関連のスケールアップの方が難しいということをおっしゃられていてDB設計の重要さを再確認しました。
RDB THE Right Way 〜壮大なるRDBリファクタリング物語〜
soudaiさんによるRDBのリファクタリングについてのお話でした。 アンケートフォームの設計を例に、RDB設計のアンチパターンをご紹介されていてとてもわかりやすかったです。 DBのテーブル設計を行う際に初めからデータの設計やデータストア選定などをしてしまいがちですが、最初にデータ設計をせずにモデリングを正しく行うことがとても重要だそうです。
またテーブルの責務はクラスの責務に似ており、テーブルのスコープを小さくすることを意識した方がよいとのことでした。 データベースの問題はすぐに顕在化するものではなくリリース後忘れた頃に顕在化するという話にはとても共感しました。
プロジェクトに途中から入った際にDB構成を理解する方法として、チームで『テーブル一覧を眺める会』を開催するとよいそうです。 中には誰も知らないテーブルが出てきたりするそうです。さっそくチームでやってみようと思います。
解決した問題の大きさがエンジニアの価値、大きな問題に立ち向かおう。という言葉がとても印象的でした。 自分もエンジニアとして、大きな問題に技術で立ち向かっていきたいです。
ブログサービスのHTTPS化を支えたAWSで作るピタゴラスイッチ
aerealさんによる、独自ドメインで運用されているはてなブログのHTTPS証明書を配信・発行する仕組みについてのお話でした。
証明書配信に関しては、はてなブログでは万単位の独自ドメインがありリクエストごとに証明書を取得・使用するため低レイテンシであることが求められます。 そのためmemcacheに証明書をキャッシュしデータストアであるDynamoDBへの問い合わせを減らすことで、レイテンシを悪化させずに証明書の配信を行なっているそうです。
証明書発行に関しては、発行リクエストが失敗し続けるとAPIの上限回数を超えてしまうため、失敗した場合に対象から外したり外部API通信のエラーを適切に処理する必要があります。 AWSのStep Functions(SFn)というワークフローサービスとLambdaを組み合わせた仕組みになっているそうです。 DynamoDBへ保存する際に設定するTTLが切れたタイミングでトリガーが発火し証明書を更新するLambda関数が呼び出され、証明書の自動更新を行なっているとのことでした。
データ自身が更新タイミングを持つことにより、更新するLambdaが更新対象を抽出する必要がなくなります。
Lambdaの責任が証明書を更新することだけに切り分けられ、関数がシンプルになるということでした。
ワーフクローエンジンのみがバッチの状態・順番を知っており、関数やクラスは状態を保存せず入力に対し処理を実行し出力するというシンプルな形にすることでバッチの複雑性を排除したそうです。
まとめ
DB設計の話や高負荷の話など、私が仕事で使っている身近な技術のお話を聞くことができとても勉強になり、たくさんの『知らなかったことを、聞く』ことができました。
カンファレンスでたくさんの知見を得たので、業務に還元していきたいと思います。
エンジニアが好きな技術や作ったもの、経験したことを熱く喋るお話はとても面白かったです!
運営の方・ご登壇の方々、素敵なカンファレンスをありがとうございました!
スタートトゥディテクノロジーズでは、一緒にサービスを作り上げてくれるエンジニアを大募集中です。 ご興味のある方は、以下のリンクからぜひご応募ください!