ほげほげふがふがもぐもぐ。

ゆるふわにかいていきたいです。

Terraform meetup tokyo#1 いってきたので超雑メモ＆感想

Terraform meetup tokyo#1

https://terraform-jp.connpass.com/event/137865/

terraform-jp meetup について @raki

https://docs.google.com/presentation/d/1OlCUT7LoHIgiwRW7-x6qSMc_m9NzVt6yIUstgwbXTvQ/edit#slide=id.p

  • コードリーディングとミートアップを交互にやっていこうと計画中

Impressions

  • 今後の計画楽しみ

スポンサー枠（HashiCorp）

https://www.slideshare.net/MasatomoIto/hashi-corp-terraform-159767595

  • terraform enterpriseについて
    • 機能
      • コラボレーション
      • ガバナンス
        • policy as a code(sentinel)
        • audit log
  • terraform enterpriseのデモ
    • setinelの例
      • リージョンを限定されたりとか、もっと複雑なことも
    • コスト管理もできる
    • module検証とかもできる

Impressions

  • 会場の4割くらい？が0.12にあげてた、あげていかなきゃ感増した

私がterraform planの差分に怯えなくなった訳 @morihaya55

https://www.slideshare.net/ssuser1f3c12/how-to-get-rid-of-terraform-plan-diffs

  • 結論
    • 出力をきちんと読めば怖くない！
  • 差分がある
    • コードが正しい or 環境が正しいを判断するのは人間
    • stateのdiffの ~ を - に置き換えればコード化できる！
      • 全部が全部ではないけれど。。。

Impressions

  • stateの置き換えは確かに感

terraform-provider-awsにcontributeして１年経ったので、振り返ってみる @kterada

https://www.slideshare.net/ssuser750dbb/contribute-to-terraformprovideraws

  • はじめてのコントリビュート
    • ドキュメントにPRから
  • contributeの進め方
    • goog first issueのタグ
    • 取り組みやすいissue
    • awsの新機能
  • contributeで困った
    • 大きなやつがなかなかレビューされない
      • 大きなやつを小分けにしたらマージされた
    • awsのドキュメントがむずい
  • contributeしてよかった
    • terraformの挙動に詳しくなる
    • awsの仕様にも詳しくなる
    • Goもちょっとわかるようになる
      • ci周りも行き届いていて勉強になる
  • core contributerに選ばれた！

Impressions

  • ドキュメントあたりからコントリビュートしていきたさ

tfschemaの仕組み @minamijoyo

https://speakerdeck.com/minamijoyo/how-tfschema-works

Impressions

  • tfschema便利そう、触りたい

How to contribute to terraform-provider-aws @chaspy

https://speakerdeck.com/chaspy/how-to-contribute-to-terraform-provider-aws

  • コードリーディングで何をしたか
    • run test
    • set debug
    • などなど
    • これのおかげで3つPRだした
  • cloneとbuildの方法
  • terraform importは対応していないやつが多いのでcontributeするのに簡単

Impressions

  • contribute意欲増してきた！

全体感想

  • contribute周りの話が多く、やってみたくなったので、気付いたポイントあたりからやり始めてみたい
  • WCは初めてやってみたけれど、色々と盛り上がってすごい楽しかった
  • 次回も楽しみ

JAWS-UG コンテナ支部 入門編 #4 いってきたメモ＆感想

JAWS-UG コンテナ支部 入門編 #4 いってきたメモ＆感想

https://jawsug-container.connpass.com/event/51776/

  • いってきたので感想が薄いけれどメモを残しておく。

19:00-19:40 『DockerとDockerHubの概念と操作』 zembutsu さん

https://www.slideshare.net/zembutsu/docker-container-image-command-introduction-2017-03

  • 今日伝えること
  • 技術と仕様
    • 技術
      • コンテナ
    • 仕様
      • docker
  • どうしてdocker?
    • サービス、アプリを作ったり、動かしたい
    • でも、みんな手元とリモートの環境違ってて困ってない？
      • そこでdocker
  • コンテナ？
    • 20世紀最大の発明とも言われてる
  • linux kernelのコンテナ化技術
  • docker engine とデーモンの変遷
    • ライブラリ：1.11〜
      • runC
      • containerd
  • dockerはサーバ、クライアントモデル
  • コンテナのプロセス
    • コンテナ内部では、独自のプロセス空間が別
      • あくまでのコンテナの中だけ
  • コンテナのファイルシステム
  • dockerの仕様について
    • dockerのイメージとコンテナの違い
      • ここが難しい
    • image
      • イメージ・レイヤの積み重ね
      • 読み込み専用
      • あくまでファイルで、メタデータの固まり
    • コンテナ
      • イメージ・レイヤを１つのファイルシステムとみなうす
      • 読み書き可能なイメージレイヤをもつ
    • 普通の仮想化との違いがあるので上記を気をつけると覚えやすい
  • dockerコンテナの実行とは
  • ここまでのまとめ
    • docker engineはdokcerイメージのファイルとカーネルの技術
  • でも、コンテナって前からあったよね？
    • ちょっと違うところ
      • docker hubがあるところ
  • [docker クライアント] -> run -> [engine] -> pull -> [docker hub]
  • イメージの自動構築機能
  • コマンドでコンテナ操作
    • イメージ操作コマンド
      • 最近コマンド体系が変わった
  • よく使うコマンド
    • docker image pull
    • docker image ls
      • ローカルイメージ一覧取得
    • docker image run
      • イメージを実行
    • docker container ls
      • コンテナの状態一覧表示
    • docker image build
      • イメージの自動構築
      • Dockerfileからの構築ができる
    • docker container commit
      • コンテナ用レイヤをイメージ化
    • docker container inspect コンテナの詳細情報表示
    • docker image inspect
      • イメージの詳細情報を表示
    • docker container diff
      • イメージとの差分
    • docker image history
      • イメージレイヤと履歴の表示
    • docker login
      • dokcer hubにログイン
    • container rm
      • コンテナ削除
    • image rm
      • イメージ削除
    • container prune
      • 不要イメージをまるっと削除
    • container prune
      • 不要イメージをまるっと削除
    • system prune
      • 不要コンテナ、イメージ、ネットワーク、ボリューム削除
      • 最近便利
    • system info, system df
      • これらも便利
  • 詳しくはqiitaにまとめてある
  • 運用麺で気をつけたいこと
    • copy in write
      • devicemapper
    • ボリュームはコンテナ用のレイヤとは分離
      • イメージレイヤの
    • 用途に応じた技術選択が鍵
  • 振り返り
    • コンテナは技術、dockerは仕様、hubは中継点、コマンドでコンテナとイメージを操作
  • 何か気になるところがあれば

Impressions

  • 最近のことを踏まえて、最新の情報と簡単な歴史を踏まえてまとめられていてわかりやすかった
  • スライドまた読み返したい

『ECS 概要/アップデート情報』AWSJ 浅野さん

[slideあったらはる]

  • 自己紹介
  • 2016/12 - 2017/03のアップデート
    • OSSでBloxリリース
      • ECSをカスタマイズしたい人向けのツール
        • 例：カスタムスケジューラを作りたい
      • 構成
    • windows serverコンテナ対応開始(β)
    • task placement policy 導入
      • タスクの配置をより柔軟にカスタマイズできる
      • task placement strategy
    • ECRが docker iamge manifest v2サポート
    • コンテナインスタンスのドレインをサポート
      • 他のタスクに影響を与えずにクラスタからコンテナインスタンスを削除可能に
      • blogに自動化の実装例ものってる
    • ECS-optimized AMIの更新通知がamazon SNSで受信可能に
  • amazon ECR
    • フルマネージドで使える docker レジストリ
      • 特徴
        • フルマネージド
        • コンテナホストと同じリージョンにレジストリを作成することで、push/pullのNWを遅延を低減
      • セキュリティ
        • https経由で通信
        • IAMと連携可能
      • amazon ECR用のクレデンシャルヘルパーを提供している
  • まとめ
    • フィードバックまってる

Impressions

  • ECS周りはそんなにおってなかったのでよかった

『とある社内ビックデータ基盤にバッチ用コンテナ環境を構築してみた』Thiro1123 さん

http://www.slideshare.net/HiroshiToda2/ss-74105091

  • 自己紹介
  • なんで導入することになったのか？
    • 背景と課題(オンプレバッチサーバ)
      • 常時300以上のジョブが実行されている
  • プロジェクトで発生してた課題
    • 日々バッチがうまく動作しない
    • アップデートしたら他のバッチが動かないなど
  • どんな状況か
    • 動いてるバッチ数が半端ない
    • 管理してるサーバも半端ない
    • ジョブ管理ソフト(JP1)も管理が追いつかない
    • アラートやモニタリングも追いつかない
      • まず手始めに
  • 現在は、新しいことしたらその倍の問題が発生しない状況
  • やりたいことは？
    • 各アプリのライブラリを依存しないように
  • バッチ単位でコンテナを用意
  • 現場からは
    • オンプレにある管理サーバからも操作できるようにしてほしい
  • バッチの実行フロー
    • 管理サーバーからはcurlでlambdaをkickする感じに
      • JP1 -> lambda -> sqs -> ECS
  • 現在は
    • 今回の仕組みを使って、オンプレからAWSに移行してる最中
  • Q&A
    • ログはどうしてる？
      • cloudwatch logsに標準出力を流すようにできるだけしてもらうようにしてる

Impressions

  • サーバー側が複雑怪奇に絡み合ってるものを紐解いて、うまい具合にコンテナのうまみを活かして改善してていい話だった

『これからECSをはじめる人のための ECSベストプラクティス』NTTソフトウェア 須藤さん

https://www.slideshare.net/sudoyu/jawsug-ecs-best-practice

  • 自己紹介
  • NTT x docker? , NTT x container ?
    • 実は結構深いつながりがある
    • dockerエンジンメンテナ、etcdメンテナ、 docker meetup tokyoオーガナイザーなどを NTTから排出してる
    • docomoのビッグデータ解析システムで、k8sと絡めて利用してる？らしい
  • こんなシステムを構築
  • アプリケーションのデリバリサイクルを早められる
    • docker imageの利用
      • アプリケーションとインフラの責任分界点が明快で、同一性が担保される世界
    • ECR + ECS
      • インフラがマネージドサービスになるので、劇的に負担が減る
    • インスタンスとサービスの分離ができる
      • ECS cluster + service
        • サービスとインスタンスが粗結合になり、マイクロサービス追加がより用意に
  • 運用コストを抑えられる
  • ECS導入のためのアプリケーション設計の勘所
    • 永続化データの設計
      • なるべく docker volumeを使わなくていいように設計する
      • ファイルはS3、ログはcloudwatch logsに、などなど
    • ログ設計
      • awslosログドライバの利用が基本
        • 後から分別したかったら、lambdaで分別するとか
      • fluentdなど、他のログドライバの検討
    • パス設計(URL設計)
      • ALBのパスベースルーティングの利用
    • データソース設計
    • セッション管理
      • ALBのsticky sessionを使う
        • 一番お手軽、ただしtask停止時にはセッションが切れる
      • State storeを使う構成にする
  • 環境構築をする時に注意すること
    • コスト最適化
      • ECSはspotfleetとの相性が非常に良い
      • spotfleetには複数インスタンスタイプを選ぶ
      • 入札アドバイザーや、スポットアドバイザーも確認
    • 最新のECS-optmized AMIの利用
      • DockerやECS agentのバージョンアップで更新される
      • 脆弱性対応が通知されたら最優先でクラスタの更新を
  • ECSでのService discovery
    • taskの変動に応じて、ターゲットグループの情報をメンテナンスしてくれる機能がある
      • 構築順序に注意が必要

Impressions

  • わかりやすさがあり、よかった
  • 多くの場合、インスタンスの利用コストよりエンジニアの稼働時間のが高い
    • ここをきちんと意識とかしていきたい

ECS導入における３つの明確な傾向 jhotta さん

http://qiita.com/jhotta/items/c6e956ca71b6f1f17de0 (スライドではないがベースはこれ)

  • datadogの調査の傾向について
  • datadogでは毎年導入に関する記事を出してる
  • 現在、datadog user 10%で dockerを使ってる
  • ３つの明確な傾向
    • トレンド１：ECSは静かに、着実に人気を獲得してる
      • ECSはバズる仕組みを持っていない
        • OSSとかではないのがやはり強い
    • トレンド２：コンテナの増加は、問題の増加
      • イメージを50以上使い始める場合、オーケストレーターが重要
    • トレンド３：オーケストレーション＝多産家系
  • まとめ
    • 多くの企業が導入を検討してる
    • コンテナオーケストレーションはコンテナ界隈のメインストリームになってくる
  • 宣伝

Impressions

全体感想

  • zembutsuさんの話はさすが感でわかりやすかった
  • Thiro1123さん, 須藤さんの話もイメージしやすかったり、コンテナ化するケースでのメリット話も納得できて面白かった
  • 現状の担当プロダクトでもちょっとずつECSのうまみが使えるとことは使っていきたいなー感

Serverless Meetup Tokyo #2 いってきたので雑なメモ

これは？

  • 社内向けに書いたmemoを折角なのでここを全然活用できていないので書くかー、みたいな感じで転載してみる。
    • よくよく見てみたら2年くらいたってたし、qiita以外にこっちも書いていかないとな感…(◞‸◟)

Serverless Meetup Tokyo #2

https://serverless.connpass.com/event/44308/

19:00-19:10 Opening: 2017年Serverless化していく世界の概況 吉田真吾 (セクションナイン)

http://www.slideshare.net/YoshidaShingo/welcometoserverlessmeetuptokyo2

  • 自己紹介
  • serverlessconf とは
    • 去年秋口に東京で開催
    • 大阪、札幌でもmeetup開催
    • FBでもコミュニティあり
  • FBでのアンケート紹介
    • serverlessでの開発でどんなツールを利用してるか
      • 1 serverless flamework
      • 2 apex
      • 3 lamvery
      • 4 swagger
      • 5 SAM
      • 6 postman
      • 7 MS VS
      • 8 aws cli
      • 9 エクリプス
    • どんな話ききたい？
      • 1 開発手法、ci/cd
      • 2 vm vs contener vs serverless in 2017版
      • 3 AI系
      • 4 api
      • 5 SPA
      • 6 serverless ストリームデータプロセッシング
  • 告知
    • serverless conf
      • 最初 Austin 4/26-28

Impressions

  • やはり、みんな開発手法とかを知りたがってるんだなぁ感

19:10-19:35 Tune Up AWS Lambda 西谷圭介 (AWS)

http://www.slideshare.net/keisuke69/tune-up-aws-lambda

  • 普段はアーキテクチャだが、今回は lambdaのパフォーマンスの話
  • 自己紹介
  • lambdaにおけるパフォーマンスに関する基本
    • 同時実行数
      • ファンクションの実行数
    • 同時実行数の考え方
      • 大前提
        • 無限ループとか用にセーフティーガードがあり、上限100
      • 大きく分けてイベントソースは２つ
        • ストリーム系(kinesis, dynamodb)の場合、シャード数と等しくなる
        • それ以外は (1sec * 関数の実行時間)
          • 例：1秒辺りのイベント数10件で、平均実行数が3秒の場合、同時実行数は 30となる
    • 同時実行数の制限緩和
      • 可能
      • とはいえ、実績がないとなかなか難しい
        • 実際に処理が行われていること
  • lambda functionのライフサイクル
    • 昔話していたが、改めて説明
    • 裏側ではコンテナとして実行(not docker)
    • 開始・再利用・終了
    • 開始
      • コールドスタート
    • 終了
    • 再利用
      • コードの変更がなく、前回の実行からそんなに時間が経っていない場合、以前のコンテナを利用
      • 再利用は保証している場合ではない
    • 凍結・再開はそんなに関係ない
  • パフォーマンスに関する設定
    • メモリ設定
      • 実際には、関数だけではなくメモリ使用率が増えればCPUも増える
      • CPUが必要な場合増やしておくと良い
    • バッチサイズ
      • ストリーム系の設定
      • 一度に取得する最大のレコード数
      • どちらが最適なのかは、ワークロード次第
  • lambda funcを早くする方法
    • コールドスタートをいかに早くするか
    • ファンクションの実行時間を短くする
    • 同時実効性をあげる
    • コールドスタートを早くする場合
      • コールドスタートを減らす
      • lambdaファンクションに対してpingする
        • 定期実行なイメージ(５分をawsではオススメ)
        • 定期的にinvokeを行うことで、コンテナが破棄されることを回避する
      • コンピューティングリソースを増やす
      • ランタイム(言語)を変える
        • JVMの起動は遅い
        • とはいえ、１度起動すると早い傾向
      • VPCを使わない
        • ENIの生成とアタッチが遅いため
        • コールドスタートを早くしたい場合、datastoreはDynamoDBが鉄則
          • どうしてもVPCの問題で利用したい場合は、DynamoDB streamをオススメしてる
      • パッケージサイズを小さくする
        • サイズが大きくなると、コードのロード、zipの展開に時間がかかる
        • 不要なコードを減らす
        • javaは肥大しがち
        • javaの場合だけ
          • POJOではなく、バイトストリームを使う
    • ファンクションの実行時間を短くする場合
      • コンピューティングリソースを増やす
      • 各言語のベストプラクティスにそうとよい
      • グローバルスコープを有効に使う
    • 同時実効性をあげる場合
      • 同期実効性の高いアーキテクチャに変えて、処理全体のスループットをあげる
      • 同期でimvokeすると、同時実行数の制限にひっかかってつまりがちなので非同期でやる
        • ほとんどのイベントソースからは非同期でトリガーされる
      • 1ファンクションの実行時間は可能な限り短くすること
  • まとめ
    • パフォーマンス関連の基本
    • lambdaファンクションを早くする
    • 同時実効性をあげることで、全体のスループットをあげる

Impressions

  • 元々興味があってもおもしろい
  • ベースの考え方は同じ感じで、あとはlambdaの制約などを理解すると当然よいな、という感じ
  • ここら辺の考え方はコンテナで動いてるということもあり、dockerなりにも思考パターンの応用として使えるのかな？

19:35-20:00 2017年のサーバレスアーキテクチャを考える - AppService/Event Hubs/Stream Analytics/Data Lake + カスタマー事例 久森達郎 (Microsoft) & 東聡志

http://www.slideshare.net/myfinder/2017-webappsevent-hubsstream-analyticsdata-lake-functions

  • インフラエンジニアリングレスアーキテクチャを考える
  • 自己紹介
    • azureは一昨年から
  • FaaSの意義って？
    • サービス単体では意味がない
    • 組み合わせることに意味がある
  • webアプリ難しい
  • コンテナも難しい
  • Azure WebApps on Linux ?
    • 現在プレビュー中
    • herokuとかに近い
    • docker hub, privateレジストリからも可能
    • dockerコンテナを投げ込める PaaS
  • DB, cacheなどのデータストアも難しい
  • ログストリーム系
    • event hubs, Stream analytics
  • ラムダアーキテクチャ
    • ログがずっと流し続けたい
  • データ処理フローの中でうまいことやりたい
  • event hubs, Stream analytics
    • kafka streamに近い
  • タイムウインドウベースの処理
  • data lake store
  • 活用のシナリオ
    • サーバーレスモバイルバックエンド
    • リアルタイムbotメッセージング
  • functionsのプログラミングコンセプト
  • サポート言語
  • サーバーレスとはなんだったのか
    • を受け取って、処理
    • つまり、サーバーレスとは21世紀のCGI

      ここから実際のユーザーにバトンタッチ

      通知周りの仕組みを azure functionで組んだ話

  • 自己紹介：@ytnobody
  • 背景事情
    • 通知サービスの選定に迷っていた
      • 一昨年の時点で契約していた
  • この手の話でよくいわれる「なんでazureに？」
    • メインのインフラがオンプレ
      • オンプレの面倒に消耗
      • 秘伝のタレ化したオンプレ
  • 通知システムの構成
    • 既存インフラ
    • azure上に新規構築
      • EventHubs / functionApp / notificationHubs / queue storege
      • functionApp
    • Event Hubs
  • 2ヶ月運用して
    • 処理数 平常時 1200件/分ほど
    • 見込んでた費用が3,40万/月くらい
    • 実際は20万/月くらい
  • まとめ
    • azureで図らずもサーバーレスアーキテクチャしていた
    • push送信は難しい
    • functionAppが簡単だった
    • だいたいみんなこんな感じのアーキテクチャになるのでは

      ここから久森達郎 (Microsoft)さん に戻る

  • インフラエンジニアリングレスアーキテクチャとは
    • インフラエンジニアをなくそう、ではなく、適材適所でやっていこう
  • もっと知りたい方は
    • 最近書籍を出した

Impressions

  • 純粋に、azureのサーバーレス周りや他のサービスを知らなかったので面白かった
  • bash serverlessは面白い
  • 安い、という話だけれど、lambdaとの比較だとどうなんだろうなー

20:10-20:30 サーバーレスAWS構成でセキュアなSPAを目指す - Cognito+API Gateway+Lambda+DynamoDB+KMS 加藤雅之 (ハンズラボ)

http://www.slideshare.net/masayuki-kato/serverless-awsspa

  • 自己紹介
  • 今日話す
    • サーバーレスAWS構成でセキュアなSPAを目指す
      • の紹介ではなく
        • 東京ハンズの考え方
          • ヒント・マーケット
          • そんな思いをここでも
  • まずはSPAのベースとなる静的サイト
    • html, jsなどをS3へ
    • より多くアクセス可能なようにCFかます
    • route53を利用
    • ACMでhttps
  • 動的な情報をjsonで返すapiの入り口
  • 動的な情報を処理するfunction
  • 情報保持
    • dynamoDB
  • api gateway
    • 適切なリソース、メソッドでlambdaを紐付け
      • RESTfulな思想
  • XSS対策のために
  • 以上で、動的でセキュアなSPA完成
  • いよいよ個別ユーザー機能
    • cognito で用意されている user poolsを使用していいが、今回はfederated identitiesを使用
  • developer authenticated identityの仕組み
    • 認証フローは複数あるが、拡張人疎湯フローを使用
    • userはうけとったtokenをSTSで使用
  • cognitoの登録
    • federated identitiesより、identity poolを作成
  • ユーザー登録lambda
    • ID/PASSのユーザー登録
  • ユーザー認証lambdaを作成
    • 作成したcognitoに対して処理を行う
  • クライアント処理とセンシティブなAPIの保護
    • 返却されたcognito tokenをクライアントに保存
    • getCredentialsForIdentityを使用
  • 有効期限に注意
    • STS Credential有効期限は最大１時間
      • cognito tokenで再取得
  • ならば json web token
  • JWTの何がいいの？
  • KMS
  • 暗号化：独自JWTの検証lambda
  • 認証を行いたいapiへ実装
    • api gatewayにてオーソライザーとしてlambdaを登録
  • 以上で、セキュアなサーバーレス
  • cognito でこんなセキュアなことも
    • S3プレフィックス

Impressions

  • 結構実運用よりな感じの話をステップ事に説明されていて面白かった
  • ここら辺の流れを再度理解していくために、スライドは何回か読み直したい

20:30-20:50 データ処理プラットフォーム in Serverless - AppEngine/Pub/Sub/Dataflow/BigQuery 福田潔 (Google)

http://www.slideshare.net/kiyo0123/noops-bigquery-cloud-dataflow

  • data + no-ops
  • 自己紹介
  • data makes software great
  • better software, faster
    • no-opsにするためには、自分たちでプラットフォームを作らなくてもいい時代へ
  • 分析に費やす時間を増やす
    • インフラではなく、データから知見を導くところにフォーカスする
  • google in 1 minute
    • googleは大きなデータに強い
    • 3M searcher, 100 hoursなどなど
  • mapreduce 後のイノベーションの歩み
    • 自分たちで使うために開発してた
  • 15年以上、データの問題に向き合ってきた
  • プロダクトにマップすると
    • 収集、保存、処理、分析、可視化
    • apache beamが正式プロジェクトに
  • BigQueryとは？
  • unstructured data accounts for 90% of enterprise data
  • Cloud Dataflowとは？
    • バッチ処理の問題点などを解決
    • Dataflowは新しいデフォルト
      • googleでは mapreduce を直接触ったりすることはもうやっていない
  • Dataflowモデル及び、Cloud Dataflow
  • spotify事例
  • シンプルに始める
    • どこから始めるかだとやはり BigQueryから始めるのがシンプル
    • 次にETLを追加
    • ストリームに対応
  • 結果は？
    • 1PBで131秒で処理が終了

Impressions

  • ところどころ、仕事できちんときけてない部分があり残念(☝◞‸◟)☝
  • あとでまた読み返して理解していきたい(☝◞‸◟)☝

21:00-21:10 Firebase+Railsのハイブリッドだからこそできた2ヶ月で2つのチャットアプリを開発した話 安尾友佑 (Redish)

https://docs.google.com/presentation/d/16C2Y-W2nzbTpDS0_Y6DWxADYG7z84eFgR069-2P57Bw/edit#slide=id.p

  • 自己紹介
    • 会社説明
  • 入社時の状況
    • 2016/08に入社
    • お客さんは賛同してた状態
  • 課題
  • Firebaseとは
    • リアルタイムデータベースとは
      • 任意のJSONをツリー上に保持
    • リアルタイムデータベースの使い方
  • Railsでの開発
    • コア機能はRailsで実装
  • カスタム認証
    • Firebase authentication
  • 完成イメージ
  • 現在
    • 周辺の粗結合なところをaws lambdaとかに
  • push通知
    • google公開のツール？を利用
  • まとめ
    • firebaseは既存のシステムとハイブリッドで利用しやすい

Impressions

  • Firebaseはちょっと面白そう（小並

21:10-21:15 Very Special LT about Apache OpenWhisk 常田秀明 (日本情報通信)

http://www.slideshare.net/hideakitokida/serverless-meetup02-openwhisk-71089759

  • 自己紹介
  • 1分でわかる OpenWhisk 背景
  • 1分でわかる OpenWhisk プログラミングモデル
  • update
    • 公式サイト
    • api gateway
      • ワンポイント機能紹介
  • お知らせ
    • ハンズオンとかやるよ

Impressions

  • オンプレ serverlessは面白そう（小並
  • 会社にあったら喜ぶ人はいそう（小並

21:15-21:20 Real World Serverless nasa (freee)

https://docs.google.com/presentation/d/1_-woxhX71qGAFFKsSXBWW6B36AOeKAemsaVTsiMfaF0/edit#slide=id.p4

  • 自己紹介
  • freeeでの利用例
    • レシート・請求書のメール転送で利用
  • 利用
    • aws lambda, sqs, s3, dynamodb, apex, lambda-local
  • 工夫したこと１
    • 既存のシステムに影響しないように
      • 不正メールが大量にきたときなど
        • dynamodb
  • 工夫したこと２
    • retryを前提
      • 合計3回
  • その他
    • リージョンをどこかのタイミングで超える必要があった

Impressions

  • リージョンまたぎの話、リトライの話は面白かった
  • もうちょっと詳しく話をきいてみたさがあった

21:20-21:25 Operation and Management with Azure Functions 工藤淳 (cloudpack)

http://www.slideshare.net/jkudo/operation-and-management-with-azure-functions

  • 自己紹介
  • 本題
    • serverless運用するのにサーバーたてる？
      • azureに限らず、ログやシステム監視でたてる必要がある
  • azure functionsの場合
    • ログが便利
    • azure functions pulse
    • azure cli
      • tailで流すことも可能
    • azure powershell
  • ログの保存
  • application insightsと連携するといい感じにできる
    • datadog, pagerdutyなども使える
    • スマート検知機能ある
  • OMSを利用してる
  • OMS Log Analytics > アラート

    • PoweBI - excelエクスポートもできる

  • azure functionsを起点にすることで、lambdaよりは Serverlessな運用が可能

Impressions

  • 運用周りの話はそんなに聞くことがなかったので面白かった
  • lambdaというか、awsでのパターンも知りたいし、考えたい

21:25-21:30 SEO対策したサイトをAPI Gateway+Lambdaで作ってみた話 平田貴大 (カラダメディカ)

http://www.slideshare.net/ssuserb2e85a/seoapi-gatewaylambda

  • 自己紹介
  • CaraCoroというプロダクトの説明
  • 今日伝えたいこと
  • 開発環境
    • Serverless flamework など
  • 本題
  • API GatewayでHTML返せばよい
  • サーバーサイドレンダリングをやるように
    • 問題はまだある
      • パフォーマンスが悪い
    • レイテンシ
  • まとめ

Impressions

  • とくになし

さいごに

  • 次回は日程未定・会場未定だが、３月くらい

全体感想

  • やはり、aws周りは実例、実運用の話が結構増えてきてて、面白かった
    • とはいえ、まだまだアーキテクチャ自体が過渡期なので、みんな苦労してる感
  • azureはazureで結構頑張ってるんだなーという印象
    • 自分がそんなに追っていないのもあるので、awsと比べた時のコストや機能などの比較はちょっと知りたい
  • google事例がなかった感じなのは、ちょっと意外
    • ここら辺も次回とかできいてみたい

滑り込み2014年振り返り

今年も残り１時間切ったので

思い至って久しぶりにポエムを書いてみる。

 

業務内容の変化

某動画システムの担当を５年以上続けていたのだけれど、チーム再編などがあり、担当を離れることになった。

新しく担当になったのは、そのシステムから分離されるアカウント部分のシステム、刷新されるアンケートシステムなどだった。

最初の半年ほどは以前よりも業務内容が逼迫してるわけでもなかったので、アンケートシステムの刷新に伴って、前任者が残していたchefを新しくしていきつつ、chefを覚えていった。

ちょうどchefが話題になって一年くらい経っていたくらいの頃で、勉強しなくてはー、と思いつつ手を付けられておらず、物凄く良いタイミングだった。

 

chefやらpackerやら

折角のタイミングであったのもあり、アサイン直後はvirtualboxのvmに古いchefのリポジトリに対してプロビジョングをして開発チームは個人開発環境を作っていたので、ここをまずはなんとかしようとした。

vagrantを利用すれば、windowsであろうとmacであろうとほぼ使い勝手が変わらないと思ったので、packerを利用して本番環境で使うkickstartファイルとほぼ同等のminimalOSなboxを作り、新しく整備していったchefのリポジトリをプロビジョングする、ということをしていった。

その過程で、チーム用のリポジトリからforkした自分のリポジトリに対してgit pushしたら、jenkinsがminimalOSなvagrant boxを起動して、chefを適当して実行がうまくいくかのテストを行ったり、

最終的にchef適用済みのboxを作成するためにforkしたリポジトリからfork元へpull requestを送って、それをjenkinsのpull request builderプラグインを使用してchef適用済みのboxを作り、開発チームに配布することができた。

ここら辺のフローとかは、社内の部内勉強会で発表したのだけれど、もうちょい整備してブログやらにしたいなーと思う（そう思ってもう三ヶ月くらい経ってるけれど(◞‸◟)）

 

ingress

個人的にここ３ヶ月くらい大ヒットしてるのがingress。

徒歩通勤での間にたくさんポータルがあったり、帰りに大回りしたりしてる間に一気にレベル8に１ヶ月くらいでなった。

その後、銀座近辺の大量ポータル承認祭りで熱が更に加熱し、自席ハックしたりしてる間にレベル9になったり、新しいメダル追加のタイミングでレベル10までいった。

11まで年内でいけるかなーとか思っていたけれど、なかなか金２つが遠く、１月中にいけたらいいなー、というのが最近の気持ちである。

 

来年に向けて

ansible

今月の頭辺りから、担当しているちょっとレガシーなシステムのansible化を行っている。

ansible化は最初は戸惑ったりしていたけれど、うまい具合にかけるようになるととても楽しかった。

syntax-checkとか実行テストとかが最初から引数であるのは便利！

でも、chefで抽象化とかの部分の考え方が身に付いてなかったら、ここまですぐに習得できてもいなかったかなぁ、とは思う。

現状は、ansibleのコード化よりも、ドキュメント化されていないあれやこれやを各環境から吸い上げてコード化する、っていう吸い上げる作業の方が想定よりも時間かかっていて、楽しみがなかなかなくなってる現状なのでさらっと終わらせていきたいところ(◞‸◟)

 

aws

担当システムでawsを利用することになってこれまた色々と勉強している。

色々とやりたいこととかやらなきゃなことはあるけれど、どこまで頭の中での理想を実現できるかなー、と言った具合なので頑張っていかないとだなぁ。

 

来年に向けて

今年に引き続き、プロビジョニングツール（chefやらansibleやら）を頑張りつつ、今年はそこまでかけなかったserverspecをもっと頑張っていきたいところ。

あとは、aws関連をもっと勉強していかないとだなぁ（担当するシステムによるけれど）

今年は世間のインフラ系技術にそこまで追い残されることなく仕事できたのが本当によかった。

ちょいちょいとqiitaに記事かけたのもよかった。

最近かけていないので、もっと書いていかねばーーーー。

といった具合で皆さん良いお年を(•́⌄•́๑)૭✧

 

ymsrさんの送別会

人生

一年くらい前に、

とりあえずとっておいたはてなブログを初めてきちんと書く。

去年末のこと。

至るところで書かれてるけれど、昨日はymsrさんの送別会だった。
最初に報せを聞いたのは、仕事中で後輩からのIMだった。
現実感が全然なくて、でも、その報せは社内で所縁のあった方々に回っていっていて、こんなにも突然で、こんなにも人生って非情なのかー、と思った。
帰宅して、周りの所縁のあった方々がネット上で悲しんでるのを見て、ちょっとずつ現実感が湧いてきて、「ああ、もういないんだ」ととても悲しくなったのを覚えている。

思い出。

当時自分がインフラを担当していたシステムのメンバーとしてアサインされてからいくらか経った頃だったか、その前だったか今となっては記憶があやふやだけれど、彼から誘われて囲まれる飲み会に行ったのが、なんやかんやと彼と飲むきっかけだったと思う。

それから色々とIRCでくだらない話をしたり、ちょいちょい開催される飲み会に呼ばれたり、呼んだりして、朝まで何度も飲んだ。

彼がいなかったら、仲良くならなかった人もたくさんいるし、今社内で色んな人と飲みに行きたいと思っていなくて、狭い世界のまま生きてたのかもしれない。


送別会。

送別会は、本当に楽しくてくだらなくて、あの場にあった悲しみよりも笑いの方が多い素敵な会だった。
あそこまで集まって、ああやってバカ笑いできる人達がたくさんいる、ということが彼の人脈と人柄の素晴らしさだったのだろうな、と思う。
だって、自分が同じようなことになっても、あんな素敵な会が行われるという想像ができないもの。

さいごに。

やましろさん、おつかれさまでした。
向こうでの美味しいお店と、笑える話、くだらない話、クズ話、たくさん期待しています。