はてなブックマーク

この記事はServerless2 Advent Calendar 2018の21日目の記事です。 qiita.com 先日 AWS Lambda Custom Runtimes芸人 Advent Calendar 2018 の方はちょっとはっちゃけすぎた感もありつつ実戦にすぐに役に立つような内容ではなかったですが、今回はマジメにより実戦的な内容で行きたいと思いますｗ marcy.hatenablog.com はじめに 私は普段は主にPythonでLambda Functionを書いているのですが、イベントの処理方法を予め決めてデコレータで共通処理を行うようにしています。それによってServerlessな開発でよく話題になるトレーサビリティの問題やエラーハンドリングの煩雑さなどをある程度上手く解決できているので紹介したいと思います。 なお、出てくるコードは実際に使用しているものに近いですが、

この記事は AWS Lambda Custom Runtimes芸人 Advent Calendar 2018 の19日目です。 qiita.com これは何？ 「Lambdaの中に入ってみたいと思ったことはありませんか？」これはそんな歪んだ願望を叶える試みです。と同時にそれを足がかりにAWS Lambdaというシステムをより深く理解するための検証とその結果を記したものです。 ちなみに毎年恒例？のLambdaのリバースエンジニアリング(?)シリーズです。 2016年 marcy.hatenablog.com 2017年 marcy.hatenablog.com Lambda Custom Runtimesとは Lambda Custom Runtimesは一般的にはAWS Lambdaが公式に対応していないプログラミング言語のRuntimeを動かすための機能です。仕様は以下の通り。 doc

題の通り、AWS Dev Day Tokyo 2018, JAWS Festa Osaka 2018で満を持してDynamoDBデータモデリングの話をしてきました。 資料 AWS Dev Day speakerdeck.com JAWS Festa speakerdeck.com 経緯 これをどこかで一つにまとめて語り尽くしたい気持ちがあって、とはいえDynamoDBのデータモデリングだけにフォーカスして語るには良いイベントが無かったので、Dev DayのCFP募集を見て「これだ！」と思って飛びつきました。 marcy.hatenablog.com で、ダメ元で申し込んでまさかの採択された後、別途内定をもらっていたJAWS Festaの３日前であることに気が付き、さすがに全く別の話を用意するのは難しいし、２回喋っても語り尽くせないくらい言いたいことが一杯あったので、どちらも同じテーマでいか

前巻のおさらい 前巻はDynamoDBのデータモデリングをするにあたって必要な考え方について、RDBとの対比を交えながら触れてきました。 marcy.hatenablog.com 今回は この巻では、実際にどのようにデータモデリングしていけば良いのかといった実践的な内容を、いくつかの汎用的と思われるパターンを例にしつつ書き記していきたいと思います。 たぶん、今までの３巻の中で一番今までの巻を理解していないとピンと来ない内容だと思うので、まずは第壱巻と第弐巻を読むことをオススメします。 Partition Keyの決め方 まずは、DynamoDBでテーブルを作る際に必ず必要な Partition Key の決め方です。前巻では以下のように書きましたが、じゃあ実際にその識別子はどうやって採番するのか？ということです。 ECサイトなら「ユーザ」「商品」「注文」といった特定の意味のある存在を表す実

前巻のおさらい 前巻はDynamoDBのデータモデリングをする前に知っておいた方が良いDynamoDB自体の仕組みやデータ構造のお話でした。 marcy.hatenablog.com 今回は 今回はデータモデリングを行う際に必要なマインドセット、つまり「考え方」について書き記したいと思います。非常によく聞かれる「RDBとの考え方の違い」といった切り口で進めていきたいと思います。 RDBとはアプローチが真逆 RDBのデータモデリングをする場合、まず正規化されたデータのスキーマを決めることから始めると思います。慣れてくると律儀に第一正規化から始めずにいきなり第三正規形あたりから設計しだすことも多いと思います（私もそうです） そして、データのスキーマが決まってからそれに対してどのようにアクセスするか（＝SQL）をアプリケーションを設計する際に考えていくというのがRDBでの一般的なアプローチではな

動機など 最近、Serverlessの文脈からDynamoDBのテーブル設計の相談を受けることが多くなってきていて、Podcastでも話したけどけっこう図とかが無いと説明しづらい領域なので、まとまった資料がほしいなということでまとめてみる。 cloudinfra.audio どう考えても長編大作エントリ不可避なので気力が続けば第二巻以降に続きます…！（フィードバックが多いと頑張れるかも…！） 本巻の対象と前提知識 本巻はDynamoDBのデータモデリングにスコープを絞っています。DynamoDBおよびデータベースの一般用語などについての説明は省きます。 前提知識としては以下のようなものになるかと思います。 DynamoDBのサービスとしての概要や用語( WCU , RCU , GSI , LSI など)を知っている Hash TableやB-Tree(B+Tree)といったデータ構造がどん

この記事は、Serverless Advent Calendar 20日目の記事です。 qiita.com もっと他のネタを書く予定だったのですが、年内タスクが沢山積んでてヤバいので去年わりと好評だったLambdaのリバースエンジニアリング？をまたやってみたいと思います。 marcy.hatenablog.com OS情報の集め方 Lambdaの実体がコンテナであることは周知の事実なので、OS情報というには語弊がある部分もあるのですが、コンテナからもホストOSの情報が部分的には見られるので他に良い呼び方も思いつかなかったんで、とりあえずOS情報と呼称します。 OSの情報を集めるのは、ChefのOhaiしかりServerspec(Specinfra)のHost Inventoryしかり、古今東西泥臭くコマンドを叩いて集めると相場は決まっています。余談ですが、ホントこういうのをやってくれるライ

この記事は、Serverless Advent Calendar 13日目の記事です。 qiita.com 今回は拙作ですがオススメのServerless FrameworkのPluginを紹介したいと思います。 概要 Serverless Alexa Skills Pluginは、Serverless FrameworkでAlexa Skill用のLambda Functionを開発しながら、スキル周辺の設定も serverless.yml および serverless(sls) コマンドから管理できるようにすることで、Alexa Skillの開発をServerless Frameworkで統合管理するためのPluginです。 github.com 経緯など Alexa Skillの開発にはLambda Functionの開発がセット Alexaのカスタムスキルを作る場合、基本的にはLa

去年に引き続き今年もスピーカーとして参加させてもらいました。 marcy.hatenablog.com 会社はスポンサーもやってるんですが、セッションとLTの両方にプロポーザルが通ってしまって余裕がないので同僚に基本任せっぱなしでした（ゴメンナサイ） 会場の雰囲気など アンダーグラウンドな雰囲気がカッコよかった去年に比べて、今年は立派なカンファレンスになった感じでした。ですが、ベンダーフリーで自由な主張が許される雰囲気は変わっておらず、正当な進化を遂げたという印象でした。去年は食事と最後のソーシャルタイム？のお酒が凄い充実していたけど、代わりに今年はノベルティのTシャツが超カッコ良いので満足しています。 ソーシャルタイムは他の登壇者や普段会えない人達と話せる良い時間だったのですが、それが無くなったのはちょっと残念です。けど、規模的にも時間的にもまあ難しいだろうなという所なので仕方ないですね

この記事は、Google Cloud Platform Advent Calenderの21日目の記事です。遅れに遅れてしまい大変申し訳ありません。。。 エントリー時は「Cloud Functionsでなにか」と書いていたのですが、イマイチ目新しい機能も出ておらず良いネタがでなかったので、過去にAppEngineで作ったComputeEngineの定期バックアップシステムの紹介をしたいと思います。 前置きと概要 AWS方面ではわりと早い段階からAPIとタグを駆使したEC2の定期バックアップ手法は有名でした。EC2にバックアップ世代数のタグを設定し、そのタグがついているインスタンスを対象にバックアップを行うバッチを定期で起動します。 blog.suz-lab.com 最近だと、CloudWatch Eventsを利用してEC2要らずで行うことができます。 qiita.com GCEでの例を見

この記事は、Serverless Advent Calendar 2016の14日目の記事です。 qiita.com 昨日は工藤さん(level69)による、「Serverless Meetup Sapporoで話てきた」でした。 工藤さんは元々北海道出身という縁もあることから、先日のServerless Meetup Sapporoに自腹で遠征してくれました。本当にありがとうございます。 serverless.connpass.com 本題 さて、本題ですが、最近はApache (元IBM) Openwiskを筆頭に、IronFunctionsなど、OSSなFaaS実装が増えてきていますが、ふと「Lambdaはどうなってんだろーなー。あ、ていうかLambdaもPythonなら、スクリプト言語だからある程度まではソースコード読めるんでは？」と思い立ったので、じゃあやってみましょうという試み

Serverless FrameworkのPluginを２つリリースしました。 経緯など 以前からLamveryというデプロイツールを作って使い続けてきましたが、イベントを繋ぐGlue Codeを管理するには我ながら便利に使えていましたし、今も使っています。 github.com ですが、複数のファンクションからなるシステムをServerlessで作るにはやはりFunction単位ではなくプロジェクトやサービス単位での管理をやりたくなる場面があって、Serverless Frameworkがv1.0で設定ファイルがYAML化して超シンプルになったのと、かなり作りが良くなって挙動をPluginで置き換えるのが比較的容易になったので、Serverless Frameworkの足りない機能や気に入らない部分をPluginで補うという方向でやってみることにしました。 LamveryのMulti F

イベント参加後の感想書くの久しぶりな気がするｗ 9/30（金）〜10/1（土）に開催されたServerlessConf Tokyo 2016に１日目のワークショップは普通に一般参加者として、２日目はスピーカーとして参加してきました。 ワークショップ 思った以上に実践的でそこそこ長丁場だったのもあって、けっこう疲れました。 ゾンビが大量発生した世界で生き残った人々が連絡を取り合うためのチャットシステムを作るみたいな感じだったのだけど、そのストーリー性のあるテーマのおかげでTwitterで参加者がわいわいしながらやっててとても楽しかったです。 その様子はこちらでご覧いただけます↓ togetter.com 内容はAPI Gatewayはやっぱりマネジメントコンソールから手動でポチポチするのツラいな・・・とか、Amazon ESやっぱ微妙だな・・・とか思ったりもしたけど全体的にはとても満足度が高

前置き ポエム系です。以下は私の見解ですが、異論は大いに認めます。 あと、エイプリルフールは全く関係ありません。ごめんなさい。 まず、本日2016.04.01、MicrosoftがAzure Functionsというサービスを発表しました。 jp.techcrunch.com azure.microsoft.com これで、AWS Lambda・GCPのCloud Functions・Azure Functionsという、三大（？）クラウドの所謂Serverlessと呼ばれるジャンルのサービスが出揃ったわけです。 AWS Lambda (サーバーレスでコードを実行・自動管理) | AWS Google Cloud Functions Documentation  |  Cloud Functions  |  Google Cloud Platform ドキュメントを読んで分かったAzure

本題 念願の（？）LambdaのVPCサポートが来ましたね！ aws.typepad.com これはもうすぐにでも使いたいやつなので、速攻で対応しました。 github.com v0.12.0～対応済みとなっております。 他にも随時機能が増えたりしてるので、以下の記事やREADMEをご確認ください。 qiita.com github.com 設定ファイルはこんな感じ vpc_config以下が該当部分です。 今後、SecurityGroupとかIDじゃなくて名前で解決できるようにしたい。 profile: private region: us-east-1 versioning: true default_alias: test configuration: name: lamvery-test runtime: python2.7 role: {{ env['AWS_LAMBDA_ROL

念のためはじめに言っておきますが会社は辞めてないですよ 色々書いて、最後のオチに持ってこようかとも思ったんですが、万が一の誤解を解くのが面倒なのでｗ 経緯 まず、私の勤めている会社で今年の春ぐらいかな？副業が解禁されました。 で、最近とある方面から個人としてお仕事のお話をいただけることがあって、その中で確定申告が必要な収入に達したので、確定申告の方法を調べていたら、どうやら副業でも個人として確定申告が必要なら個人事業主になった方が節税になるという情報を得て、ちょっとやってみようかなと思い立ったわけです。副業の対象に個人事業主は想定されていなかったんですが、試しに相談してみたら規定を見なおしてOKもらえました。会社に感謝です。 安定して月収5万～10万円なら個人事業主を検討しよう まあ、今現在安定して月収5万～10万円の保証なんてどこにもないわけですが・・・ 正直、節税は割りとついでの意味合

はじめに 大抵、インフラのコード化を始めるのって新規システムとかになると思います。 たしかに、最初からやる方が途中からやるのに比べて遥かに敷居が低く、費用対効果も高いと言えると思います。 まあ、インフラのコード化に限らず、TDDとかもそうです。 新しいことを始めるのは最初からの方がやりやすい。 これが、既存システムの場合は 今動いているものが壊れたらどうする？ 既に出来上がっちゃってるものにそんなにコストかけてやる必要ない とかいう感じで、コストやリスクと得られるメリットを天秤にかけた結果、敬遠されがちなのかなと思います。 たぶん、比較対象のメリットは以下の様なものでしょう。 自動化による人的コスト減 再現性のあるインフラによる追加開発やメンテナンスの効率と質の向上 モチベーションアップ でも、やったことがある人には判るかもしれませんが、実はもっと重要なメリットというか、意義があるんです。

AWS SDK for Go（のベータ版）が出たので触ってみたくて作ってみました。 最近の（自分の周りの）EC2バックアップ事情 EC2の定期バックアップは特に受託案件だとほぼ必須で各社・各個人で色々な方法でやっていることと思います。 最近だとお金があるなら「Cloud Automator使え」ってなるんですが、僕らのような貧者は昔からEC2のタグを見てバックアップを行うスクリプトをcronで回していたり、Jenkinsおじさんにお願いしたりするわけです。 で、一括管理できるようにアカウント横断で共用サーバ上で回すのが楽なわけですが、必ずしもそうできないような場面も会って、そうなるとスクリプトを別のサーバに仕込むわけです。 ただ、そうやってバックアップスクリプトが増殖していくと、そのうちAPI仕様変更とかSDKのバージョン違いによるバグ踏んじゃったりとか、Chefとかがあるとはいえそのため

前置き ポエムであり、最後の方ステマっぽいです（そんなつもりは全くなかったんですが、思うままに書いていたらそうなったｗ） 基本的に具体的な論拠に基づかない個人的な感覚で書いてます。ちょっと煽りっぽいですが「そんな風に話をしたくなる時もあるよね」と生暖かい目でお読みいただけると幸いです。 あと、もちろん「今オンプレを使っている人」を否定する意図は全くありません。そこに様々な事情があることは重々理解しておりますし、場面によっては未だオンプレにアドバンテージがある部分も残っていることは承知しております。 言いたいことは、「揺り戻しはクラウドを使わない理由には全くならない」ということです。 まずはじめに たまにこの言葉を聞く。 「クラウドクラウドって言ってるけど、過去の技術がそうであったように、いずれまたオンプレに戻ってくる日が来る」 この後は「だからクラウドは～」と続く。 たしかにそうかもしれな

前回の Azure Job Scheduler + AWS Lambdaで夢のサーバレス定期ジョブを実現する - Miscellaneous notes 続きです。 今回はまだ考察・アイデアレベルでまだ試してません（そもそも、このアイデアについてのコメントなどいただけることを期待していたりいなかったりｗ） 実際にやりたいジョブはそう単純じゃない 単一または少ない数の単純なジョブであれば、S3バケットと1:1で紐づけてやっても良いかと思います。 でも、実際にやりたいことはそうじゃなかったりします。 複数のジョブをまとめて実行したかったり、対象が多いために並列で一気に処理したかったりするわけです。 Azure Job Schedulerに登録できるJob数にもS3バケット数にも上限がありますし、大量のJobを効率的に管理する必要があります。 従来では ジョブの発行者（Publisher）と実行

GoAzureがやっていたので、フラフラとAzureのWebサイトを見ていたりしました。 で、Azureのサービスの中に、AWSには無いJob Schedulerのサービスがあって、 これずっと欲しかったやつや！ ってなったので、ちょっと調べてました。 余談ですが、Jobの発行元の可用性担保と実行保証って面倒くさいんですよね。二重発行させる訳にもいかないですし、そのためだけにHA組む？みたいな所もあり… 発行されたJobを実行する所ではSQSとかELBとか挟めばどうとでもなるんですけど… そんな訳で、フルマネージドなJob Schedulerはとても魅力的なわけです。 で、まず思ったのが「ここからLambdaキックできたらサーバレス定期ジョブでアツいなー」ってことです。 Job Schedulerができることは大別して以下の2つです。 同じAzureのStorage Queueへのメッセー

この記事は Chef Casual Advent Calendar 2014 の25日目の記事です。 Chef Advent Calendar 2014 - Qiita お詫び 元々はCookbookの書き方、あるいはNginxの設定ファイルの書き方というタイトルでエントリーしておりましたが、自分の中で優先順位の変化がありましたので別のテーマで書かせていただきます。 Cookbookの書き方、あるいはNginxの設定ファイルの書き方は自分の書き方、考え方が合っているかの確認も込めて書こうと思っていましたのでまた今度書きます。 これは何？ Dockerコンテナ上でtest-kitchenによるテストを行うためのDriver Pluginです。 インストール方法や使用方法は下記のREADMEをご確認ください。 marcy-terui/kitchen-docker_cli · GitHub ki

こんばんは。最近、MySQLじゃなくPostgreSQLを触っていますが、心はいつもMySQL派な @marcy_terui です。 この記事は MySQL Casual Advent Calendar 2014 の15日目の記事です。 ちょっと16日目にかかってしまったので、怒られやしないかとgkbrしてま（ｒｙ MySQL Casual Advent Calendar 2014 - Qiita 「Amazon RDS」vs「オレオレRDS的な何か」 #とは ベンチマーク対決とかじゃありません。 日頃お世話になっている便利なRDSさんですが、そんな便利さに甘んじて… 「RDS以外でまともにMySQLを運用できない」 なんてことにならぬよう、 「俺のRDS」が「Amazon RDS」にどこまで迫れるか 的な意味での対決になります。 また、その無駄な車輪の再発明を通して、改めてMySQL及び

この記事は、AWS Advent Calendar 2014 - Qiitaの8日目（もう9日になっちゃいましたが）の記事です。 これからPythonをやることになったので、 兼ねてより気になっていたKCL(Kinesis Client Library) for Pythonを試してみようかと思いやってみました。 試しに何か作ってみようってことで安易なんですが、 ①Twitter Streaming APIからストリームデータを取得してKinesisへ流す ②KCLで受けて特定のワードが出てきたらGraphiteに送信 ③グラフ化 という感じの(準)リアルタイムトレンドグラフみたいなものを考えました。 こんな感じですね。 …が、大半できた所で謎のエラーでハマり、時間切れになりましたorz 原因追求して追試したいと思いますが… やってみて、けっこうコレつらいやつなのではと思いましたｗ 手順と

この記事は、mod_mruby ngx_mruby Advent Calendar 2日目の記事になります。 「分かったこととか、ちょっとしたノウハウ（レベル低いやつですｗ）とか、感想とか」とエントリーしましたが、全部まとめて書くとエライ長くなりそうなのと、情報がまぜこぜになって読みづらくなりそうなので、幸いアドカレの枠にまだそれなりに空きがあるようですので分割させていただきますm(__)m ここではまず、やってみて「分かったこと（というかやってて気づいたこと）」と「感想」の辺りを書きたいと思います。 ノウハウについては5日目に書こうと思います。 きっかけ まず、常々出たいとは思っていたものの、相棒が居ないので出れなかったISUCONの予選問題が公開され、それを普段使っていた（現在はPythonの会社に転職したので過去形）PHPでやってみたりしてました。 isucon4予選AMIが公開され