01/23(水) は「Hatena Engineer Seminar #11 @ Tokyo」に参加してきました。
会場は 株式会社はてな 東京オフィス SHIBAFU。
結構長い間はてなユーザーだったのですが、オフィスに来たのは初めてだぞー(笑)
思い返せばこの記事を見て、なんかいい場所だなぁ、行ってみたいなぁと思っていたけど、記事の日付を見たら2012年。もう6年以上前なのか。
目次
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回聞いた感じで結構満腹感(笑)があります。その分、一つ一つのセッションが消化不良気味になりがちと思うので、足りない部分は懇親会で直接聞くスタイルのようです。参加者としても話すネタを用意してもらっているような形なので、話を聞くだけよりこの方が良いかもな、と思いました。
資料はTwitterに流す感じでは無いようなので、公式からの開催レポートが公開されるまでは待ちです。
マンガチームとDevOps
id:miki_bene さん
はてなで開発しているマンガのビュアー、「Giga Viewer」でクラウドをどうやって活用してどいうDevOpsを実践しているのか、という内容。 なんではてなでマンガのビュアーを開発しているのか、というのを探したらこんなエントリが見つかりました。
「権利者への支払いをしたうえで、マンガサイトを優れたサイトにしたい」とアツい想いが語られているので、マンガのビュアーに興味がある人は読んでみてください。
セッション自体はマンガビューアーの話と言うよりは、その開発体制の話でした。
ざっくり書くと
- マンガビューアーは受託開発
- クラウドを活用したインフラ上でシステムを構築
- インフラや運用はSREやインフラの担当に依頼していた
- SREはチームにJOINするのではなく、全体横断的な立ち位置で参画
- この形だと知見が開発側に残らず、SREの負担が高くなってもサポートも出来ない
- アプリケーション開発のエンジニアもSREのやっているOpsの部分をできるように
- 開発に近いところから。一気にやろうとせず、わかるところを増やしていく感じで
- SREとアプリケーションエンジニアのペアオペ体制。
- 聞いたり操作したりすることに集中すると、記録が疎かになりがちなのでペアと言いつつ書記がいるのは良い。
- 手順書古びる問題。できるだけ自動化。
- CloudFormationでS3バケット作成などから。
開発と運用って一緒にできたほうがやっぱり動きやすいよね。
— kabukawa (@kabukawa) 2019年1月23日
運用のことを考えながら開発すると、作り方とか作るときの考え方が変わる気がする。
#hatenatech
触るまでは怖いのでやりたくない気持ちはよく分かる。
— kabukawa (@kabukawa) 2019年1月23日
でも、コードで書けることがわかれば、開発者でも意外とすんなり始められる、という感覚もある。練習できれば始めやすいんだけどねー。
#hatenatech
天然データレイクに飛び込むところからはじめるグロースハック
id:polamjag さん
[資料は公開されたら追記します]
はてなのサービスのログなどのデータをGCPのBigQueryやAmazon Athenaを使って数値にして分析/可視化するという内容。
それぞれのサービスについては以下のリンクから、どんな事ができるかをたどってみてください。
DBのログなどの巨大データを分析するときは BigQuery や Athena を使うと色々捗る、という今どきの話でした。
ざっくり書くと
- グロースハック:主に開発の面で工夫をして、サービスの改善をモニタリングしながらサービスを成長させること
- モニタリング?ログなどのデータを数値化して分析
- 単純な方法:スクリプトでスプレッドシートへ更新するバッチを定期実行
→ 結構面倒。見てみたいレベルの集計のためにALTER TABLEとか辛い - BigQueryはうまい安い早い銀の弾丸
- 東京リージョンだとストレージの単価はS3よりBigQueryのほうが安い
- S3に既にデータが大量にある場合はAthenaが便利
- Athenaを使えばBigQueryのように使わなくても grep as a service として使える
- はてなではLTSVフォーマットで作成されたファイルが結構ある
Athenaはうまく使わないと結構高くつくイメージ。
— kabukawa (@kabukawa) 2019年1月23日
#hatenatech
パーティショニングしないでAthena使っているのか。
— kabukawa (@kabukawa) 2019年1月23日
ふ、太っ腹だ。。。。
#hatenatech
システム基盤としてのAWS活用
id:cohalz さん
AWSのLambda や CloudFormation を活用して運用の改善をしている、という内容。
LambdaにはSAM(Serverless Application Model)というフレームワークがあって、それを活用しているそうです。 話を聞くまで知らなかったのですが、サーバーレスアプリケーションのフレームワークのテンプレートだけでなく CloudFormation スタックに変換するコードとかも含まれているようで、良さそうですね。
具体的に2つの事例で、どのような活用の仕方をしているのかが説明されていました。
ざっくり書くと
- 従来はEC2のリタイアイベントを手動で対応していた
- これが結構たいへんなので自動化したい、というモチベーション
- CloudWatchイベント → Lambda → Slack bot を使って GitHub Isuue と Googleカレンダーへ登録
- 証明書管理システム
ACM(AWS Certificate Manager)があるのでLet's encryptは不要ではないか?
AWSの公式ツールを使ってればサポートに聞ける自動化を進めたが、他の人もメンテができるようにドキュメントを整備
- CloudFormation の yaml が巨大になると思うがレビューなどは大変ではないか?
→ 大変だけどがんばる - マルチアカウント対応はどうやっているのか?
マルチアカウントの場合はCloudWatchのイベントを他のアカウントに流す
自動化して手順書によらない作業にしたけど、それによって見えなくなる部分ができるので更に全体を分かるためのドキュメントが必要になる、と。メチャ分かるけど、もにゃっという気持ちが。。。
— kabukawa (@kabukawa) 2019年1月23日
#hatenatech
YAMLを可視化するツールがほしい人は多いのではないか説。
— kabukawa (@kabukawa) 2019年1月23日
#hatenatech
Mackerel をオンプレミスから AWS に移してからの1年半を振り返る
id:astj さん
[資料は公開されたら追記します]
タイトルの通り、Mackerel をオンプレミスから AWS に移行したにやったことや時の苦労などについての内容。
話としては以下のスライドの最後の方に書かれている AWS移行 の話になるんだと思います。このスライドを見て「この辺の話をブログで読んだりしてすげーって思ってたな。懐かしい」と思うのはおっさんですかそうですか。
オンプレからクラウドへの移行って単純に動く場所を変えるのも有りなんだけど、クラウドのメリットを活かした構成にしたほうが後々楽だったりするのと、今動いているものを一括で移行するのはメチャ大変だしリスクもあるのでフェーズを切って移行するというやり方をしたと聞いて、ちゃんと考えられているんだなぁと妙なことに感心してました。(実際問題、クラウドクラウド言われているから取り敢えず動く場所変えました、で満足している会社も多いのではないかと思ってます)
内容は、ざっくり書くと
- MacarelのDBはPostgreSQL
- TSDB(時系列データベース)
- オンプレのときは ioDrive を使って圧倒的なディスクパフォーマンス
- 但しメチャ高い。スケールアウトも大変
- TSDBとしてはGraphite(OSS)を使っていた。
- Graphiteはそもそもインハウス用途なので、マルチテナントなSaaSにはフィットしない部分があった
AWSに移行後は Diamond(内製)に切り替え
名前の由来は Graph -> Graphite -> Diamond (炭素仲間) だそうです。TSDBはオンプレとクラウドで並行運用
- mackerelのTSDBをmackerelで監視していた
- その後段階的に機能をクラウドへ
- オンプレとクラウドに同時書き込みで性能面は大丈夫だった(Direct Connect、つまり専用線を張っているので)
- DB切り替えが重かった(でも時間の関係でスライドは飛ばされた(笑))
- 金なら払うからスケールしてくれ!(わかる)
- 移行の話はこちらのスライドにも書かれています。
オンプレと同じやり方でクラウド移行してもうまくいかないので、こういう知見は大事だと思う。
— kabukawa (@kabukawa) 2019年1月23日
#hatenatech
MySQL自前運用やめてAurora導入する話
[資料は公開されたら追記します]
はてなの中で古めのサービスのインフラ周りを扱うチームで運用している MySQLをAWS のRDS(Aurora)へ移行するという内容。
はてなでは歴史的経緯(?)によりMySQL 4.0で動いているサービスもあったそう。様々なバージョンがあると保守も大変になるので、これをまず、MySQL 5.6へ移行したけど、どうせならマネージドサービスへ移行してアウトソースすることで、コスト面と人的リソース面での効率化を図ろうという話でした。
MySQLの古いバージョンからの移行の話はこちらのブログエントリに詳しく書かれています。メチャ大変だったことが分かるし、お疲れ様でしたと言いたい、、、
で、バージョンを社内基準まで上げたので、MySQL自前運用やめてAurora導入しようという話に繋がります。
内容は、ざっくり書くと
- インフラオーナーシップというのは「信頼性と費用をサービス開発チームが責任を持つ」というもの
- Aurora は MySQL互換を謳っているのでMySQLユーザーから見れば新規の学習コストはそれほど高くない
- マネジメントコンソールでポチポチできる
- とはいえ、今まで意識していなかったインフラをいきなり理解するのは難しい
- マネージドなので難しいことをしなくても解決できてしまう
- とにかく分かってもらえるまで話をしていくしか無い
- フェイルオーバーや取り返しがつかない操作についてまず説明する
- ハンズオンを実施するなど、使ってみて「怖くない」を実感してもらう
マネジメントコンソール使えるならだいぶ楽になると思う。
— kabukawa (@kabukawa) 2019年1月23日
AWS CLIで一通りの操作をできるようにってやってたことがあるけど、最初はマネコンでポチポチできるだけでだいぶ障壁が下がる気がする。
#hatenatech
懇親会
勉強会の後で懇親会も行われました。ソフトドリンクになんと瓶のコーラが!
懇親会! #hatenatech pic.twitter.com/Ff1FTuvVBg
— kabukawa (@kabukawa) 2019年1月23日
懇親会では、セッションでは聞けなかった話を、エンジニアの方から色々聞くことが出来ました。 そもそも東京での開催なので東京のエンジニアの人が喋っているんだと思っていたら、東京の人は2人だけであとは京都から来ていたという話にはビックリ。 まぁ、はてなは京都が本社なのでさもありなんとは思いましたが、遠くからありがとうございましたとい気持ち。 めちゃ一人で色々聞いていたので、ウザいおっさんやな、と思われていないか心配になりました(汗
まとめ
取り敢えず色々興味深い話も聞けたし、参加できてとても良かったです。 自社開催ということもあるんでしょうけど、エンジニアの方もリラックスした雰囲気の中で、とてもいい時間を過ごすことが出来ました。
次回もまた参加できればと思います。ありがとうございました!