Above & Beyond

日々のアウトプット記録

Hatena Engineer Seminar #11 @ Tokyo

01/23(水) は「Hatena Engineer Seminar #11 @ Tokyo」に参加してきました。

hatena.connpass.com

f:id:kabukawa:20190120115106p:plain:w500

会場は 株式会社はてな 東京オフィス SHIBAFU。

f:id:kabukawa:20190123185337j:plain

結構長い間はてなユーザーだったのですが、オフィスに来たのは初めてだぞー(笑)
思い返せばこの記事を見て、なんかいい場所だなぁ、行ってみたいなぁと思っていたけど、記事の日付を見たら2012年。もう6年以上前なのか。

blog.kushii.net


目次


Hatena Engineer Seminar とは

株式会社はてなが主催する技術勉強会です。

そう、今皆さんが見ているこのブログサービスを運営している会社です。はてなといえばはてなブックマーク、通称 "はてブ" が有名と思ってましたが、今は "はてブ" というと "はてなブログ" を指していると思う人も多いようです。時代の流れですかね。。。

技術勉強会ということで、はてなのエンジニアが直接、自分たちの使っている技術の話が聞ける場だと思います。もちろん、「We are hiring!」な話もありますので、はてなで働いてみたいなという人が参加すると、エンジニアに直接話を聞けて良いかもしれません。


何故参加したか

はてなの主催する勉強会、MackerelのMeetupは参加したことがあるのですが、Hatena Engineer Seminar は初参加です。 元々はてなという会社は技術的なトピックなどはブログなどを通じて積極的に外に発信していて、技術ブログなどはRSSリーダーに突っ込んで読んでいました。なのでどんな感じなのかのイメージは有ったのですが、直接話しを聞いてみたほうが面白いだろうし、ぶっちゃけ、ブログで見たあの場所に行ってみたいというミーハーな気持ちで参加しました(をい)


タイムテーブル

時刻 名前 タイトル 時間
19:00 - 開場・受付開始 -
19:20 - 開会の挨拶・諸注意 5分
19:25 id:miki_bene マンガサービスを支えるクラウド活用とDevOps 15分
19:40 id:polamjag 天然データレイクに飛び込むところからはじめるグロースハック 15分
19:55 id:cohalz システム基盤としてのAWS活用 15分
20:10 - 休憩 10分
20:20 id:astj Mackerel をオンプレミスから AWS に移してからの1年半を振り返る 20分
20:40 id:t_kyt MySQL自前運用やめてAurora導入する話 20分
21:00 - 休憩・準備 5分
21:05 - 懇親会 45分
21:50 - お開き -

内容

それぞれのセッションは15分~20分と内容の割に短めだったのですが、間に休憩が1回だけなので感覚的には40分のセッションを2回聞いた感じで結構満腹感(笑)があります。その分、一つ一つのセッションが消化不良気味になりがちと思うので、足りない部分は懇親会で直接聞くスタイルのようです。参加者としても話すネタを用意してもらっているような形なので、話を聞くだけよりこの方が良いかもな、と思いました。

f:id:kabukawa:20190123192104j:plain:w500

資料はTwitterに流す感じでは無いようなので、公式からの開催レポートが公開されるまでは待ちです。


マンガチームとDevOps

id:miki_bene さん

speakerdeck.com

はてなで開発しているマンガのビュアー、「Giga Viewer」でクラウドをどうやって活用してどいうDevOpsを実践しているのか、という内容。 なんではてなでマンガのビュアーを開発しているのか、というのを探したらこんなエントリが見つかりました。

jusei.hatenablog.com

「権利者への支払いをしたうえで、マンガサイトを優れたサイトにしたい」とアツい想いが語られているので、マンガのビュアーに興味がある人は読んでみてください。

セッション自体はマンガビューアーの話と言うよりは、その開発体制の話でした。

ざっくり書くと

  • マンガビューアーは受託開発
  • クラウドを活用したインフラ上でシステムを構築
  • インフラや運用はSREやインフラの担当に依頼していた
  • SREはチームにJOINするのではなく、全体横断的な立ち位置で参画
  • この形だと知見が開発側に残らず、SREの負担が高くなってもサポートも出来ない
  • アプリケーション開発のエンジニアもSREのやっているOpsの部分をできるように
  • 開発に近いところから。一気にやろうとせず、わかるところを増やしていく感じで
  • SREとアプリケーションエンジニアのペアオペ体制。
  • 聞いたり操作したりすることに集中すると、記録が疎かになりがちなのでペアと言いつつ書記がいるのは良い。
  • 手順書古びる問題。できるだけ自動化。
  • CloudFormationでS3バケット作成などから。


天然データレイクに飛び込むところからはじめるグロースハック

id:polamjag さん

[資料は公開されたら追記します]

はてなのサービスのログなどのデータをGCPのBigQueryやAmazon Athenaを使って数値にして分析/可視化するという内容。

それぞれのサービスについては以下のリンクから、どんな事ができるかをたどってみてください。

cloud.google.com

docs.aws.amazon.com

DBのログなどの巨大データを分析するときは BigQuery や Athena を使うと色々捗る、という今どきの話でした。

ざっくり書くと

  • グロースハック:主に開発の面で工夫をして、サービスの改善をモニタリングしながらサービスを成長させること
  • モニタリング?ログなどのデータを数値化して分析
  • 単純な方法:スクリプトスプレッドシートへ更新するバッチを定期実行
    → 結構面倒。見てみたいレベルの集計のためにALTER TABLEとか辛い
  • BigQueryはうまい安い早い銀の弾丸
  • 東京リージョンだとストレージの単価はS3よりBigQueryのほうが安い
  • S3に既にデータが大量にある場合はAthenaが便利
  • Athenaを使えばBigQueryのように使わなくても grep as a service として使える
  • はてなではLTSVフォーマットで作成されたファイルが結構ある

d.hatena.ne.jp

  • AthenaだとSQL正規表現が埋め込めるので、LTSVの検索もできる
  • BigQuery や Athena を使うといろいろ捗るよ!


システム基盤としてのAWS活用

id:cohalz さん

speakerdeck.com

AWSのLambda や CloudFormation を活用して運用の改善をしている、という内容。

LambdaにはSAM(Serverless Application Model)というフレームワークがあって、それを活用しているそうです。 話を聞くまで知らなかったのですが、サーバーレスアプリケーションのフレームワークのテンプレートだけでなく CloudFormation スタックに変換するコードとかも含まれているようで、良さそうですね。

github.com

具体的に2つの事例で、どのような活用の仕方をしているのかが説明されていました。

ざっくり書くと

  • 従来はEC2のリタイアイベントを手動で対応していた
  • これが結構たいへんなので自動化したい、というモチベーション
  • CloudWatchイベント → Lambda → Slack bot を使って GitHub Isuue と Googleカレンダーへ登録
  • 証明書管理システム

developer.hatenastaff.com

  • ACM(AWS Certificate Manager)があるのでLet's encryptは不要ではないか?
    AWSの公式ツールを使ってればサポートに聞ける

  • 自動化を進めたが、他の人もメンテができるようにドキュメントを整備

  • CloudFormation の yaml が巨大になると思うがレビューなどは大変ではないか?
    → 大変だけどがんばる
  • マルチアカウント対応はどうやっているのか?
    マルチアカウントの場合はCloudWatchのイベントを他のアカウントに流す


Mackerel をオンプレミスから AWS に移してからの1年半を振り返る

id:astj さん

[資料は公開されたら追記します]

タイトルの通り、Mackerel をオンプレミスから AWS に移行したにやったことや時の苦労などについての内容。

mackerel.io

話としては以下のスライドの最後の方に書かれている AWS移行 の話になるんだと思います。このスライドを見て「この辺の話をブログで読んだりしてすげーって思ってたな。懐かしい」と思うのはおっさんですかそうですか。

songmu.github.io

オンプレからクラウドへの移行って単純に動く場所を変えるのも有りなんだけど、クラウドのメリットを活かした構成にしたほうが後々楽だったりするのと、今動いているものを一括で移行するのはメチャ大変だしリスクもあるのでフェーズを切って移行するというやり方をしたと聞いて、ちゃんと考えられているんだなぁと妙なことに感心してました。(実際問題、クラウドクラウド言われているから取り敢えず動く場所変えました、で満足している会社も多いのではないかと思ってます)

内容は、ざっくり書くと

  • MacarelのDBはPostgreSQL
  • TSDB(時系列データベース)

twitter.com

  • オンプレのときは ioDrive を使って圧倒的なディスクパフォーマンス
  • 但しメチャ高い。スケールアウトも大変
  • TSDBとしてはGraphite(OSS)を使っていた。

graphiteapp.org

  • Graphiteはそもそもインハウス用途なので、マルチテナントなSaaSにはフィットしない部分があった
  • AWSに移行後は Diamond(内製)に切り替え
    名前の由来は Graph -> Graphite -> Diamond (炭素仲間) だそうです。

  • TSDBはオンプレとクラウドで並行運用

  • mackerelのTSDBをmackerelで監視していた
  • その後段階的に機能をクラウド
  • オンプレとクラウドに同時書き込みで性能面は大丈夫だった(Direct Connect、つまり専用線を張っているので)
  • DB切り替えが重かった(でも時間の関係でスライドは飛ばされた(笑))
  • 金なら払うからスケールしてくれ!(わかる)
  • 移行の話はこちらのスライドにも書かれています。

speakerdeck.com


MySQL自前運用やめてAurora導入する話

id:t_kyt

[資料は公開されたら追記します]

はてなの中で古めのサービスのインフラ周りを扱うチームで運用している MySQLAWS のRDS(Aurora)へ移行するという内容。

はてなでは歴史的経緯(?)によりMySQL 4.0で動いているサービスもあったそう。様々なバージョンがあると保守も大変になるので、これをまず、MySQL 5.6へ移行したけど、どうせならマネージドサービスへ移行してアウトソースすることで、コスト面と人的リソース面での効率化を図ろうという話でした。

MySQLの古いバージョンからの移行の話はこちらのブログエントリに詳しく書かれています。メチャ大変だったことが分かるし、お疲れ様でしたと言いたい、、、

developer.hatenastaff.com

で、バージョンを社内基準まで上げたので、MySQL自前運用やめてAurora導入しようという話に繋がります。

aws.amazon.com

内容は、ざっくり書くと

  • MySQL 4.0 -> 5.6移行に比べたらAurora移行の技術的障壁はそんなになかった
  • はてなではインフラオーナーシップという考え方を推進している

speakerdeck.com

  • インフラオーナーシップというのは「信頼性と費用をサービス開発チームが責任を持つ」というもの
  • Aurora は MySQL互換を謳っているのでMySQLユーザーから見れば新規の学習コストはそれほど高くない
  • マネジメントコンソールでポチポチできる
  • とはいえ、今まで意識していなかったインフラをいきなり理解するのは難しい
  • マネージドなので難しいことをしなくても解決できてしまう
  • とにかく分かってもらえるまで話をしていくしか無い
  • フェイルオーバーや取り返しがつかない操作についてまず説明する
  • ハンズオンを実施するなど、使ってみて「怖くない」を実感してもらう


懇親会

勉強会の後で懇親会も行われました。ソフトドリンクになんと瓶のコーラが!

懇親会では、セッションでは聞けなかった話を、エンジニアの方から色々聞くことが出来ました。 そもそも東京での開催なので東京のエンジニアの人が喋っているんだと思っていたら、東京の人は2人だけであとは京都から来ていたという話にはビックリ。 まぁ、はてなは京都が本社なのでさもありなんとは思いましたが、遠くからありがとうございましたとい気持ち。 めちゃ一人で色々聞いていたので、ウザいおっさんやな、と思われていないか心配になりました(汗


まとめ

取り敢えず色々興味深い話も聞けたし、参加できてとても良かったです。 自社開催ということもあるんでしょうけど、エンジニアの方もリラックスした雰囲気の中で、とてもいい時間を過ごすことが出来ました。

次回もまた参加できればと思います。ありがとうございました!