サーバーレス技術の今と未来についてServerlessDays TokyoのPreEventで話してきました - めもおきば
𝕏にURL貼れなくなっているので、Zennにもマルチポストしています。 ServerlessDays Tokyo 2024 PreEvent 2024-09-21のServerlessDays Tokyo 2024にむけて、去年に引き続き、直前イベントでサーバーレス技術の今と未来について話してきました。 いよいよ明日からメインイベントですので参加お待ちしています！ Serverless Update 2024 文字起こし スライド全体はDocswellさんで公開しています。 PreEventはYouTubeでアーカイブがあります。 サーバーレスのおさらい 「サーバーレス」は、誤解を招きやすい技術用語で様々な定義がありますが、ここでは2つの視点で定義します。 運用者の視点としてのサーバーレスは、物理的なマシンや仮想マシン、EC2インスタンスのような「サーバー」を自分で管理するのではなく、そ
#ssmjp で最近のサーバーレスの話をしました - めもおきば
2/16のssmonline #32にて、「最近のサーバーレスの話」を話してきました。 スライドはこちら： 最近のサーバーレスの話 #ssmjp by @nekoruri おさらい：サーバーレスってなんだっけ？ まずは軽くおさらいからです。 サーバーレスは性質をあらわしているので0／1であてはまるものではないですが、やはり完全従量課金という課金モデルに近づける努力をしているものをそう呼んでいきたいところですね。 最近のサーバーレス開発 サーバーレスといえば、FaaS（AWS LambdaやAzure Functions）で様々なサービスをイベントドリブンでつないでいくアーキテクチャが注目されてきました。「もう古い」はちょっと盛りましたが、単純にFaaSで処理をつなぐのでは、そういったイベントドリブンな「ピタゴラ装置」を管理するのが大変です。 失敗時の再送や、異常データの除外（DLQへの積み
LayerXに転職しました - めもおきば
まる6年お世話になったWHEREを退職し、2月からLayerXではたらいています。 WHEREでの6年間 だいたい3年くらいで転職していることが多いので、6年というのは過去最長でした。まあうしろの2年くらいはほとんど成果が出せていなかった(後述)ので、実際の長さとしてはそれほど変わらずかもしれません。 WHEREでは、ちょうど自分が入ったタイミングではじめたIoTビジネスにおいて、デバイス管理のためのデータ処理基盤を担当していました。 いわゆるお客さんに面するSaaS本体の部分は内部APIを介して別チームが見ていて、実際のデバイス側と向き合ってデータの送受信を受け持ち、センサーデータの一次処理などもここでやっています。Bluetoothメッシュネットワークを活用したEXBeaconという独自デバイスも作っていたので、立ち上げ期はエッジ側のゲートウェイの実装とかも見ていました。ウェブエンジニ
IoTデータ処理の考え方 - めもおきば
世の中いろいろな「IoT」がありますが、突き詰めればデバイスから上がってくるデータを処理して何かを実現するのがIoTです。IoTにおけるデータ処理を考える上で、ネットワークプロトコルの設計指針を参考にするとうまく整理できます。 シンタックス、セマンティクス、そしてコンテキスト ネットワークプロトコルを設計するときにはシンタックス（Syntax; 文法）とセマンティクス（Semantics; 意味）に分けて考えます。そしてネットワークプロトコルの外側にあるコンテキスト（Context; 文脈）に基づいて処理が行われます。 それぞれ掘り下げていきます。 シンタックス：どのようにデータをやりとりするか どのようにデータを送り、受け取るかという「文法」を決めるのがシンタックスです。 たとえばHTTPであれば、HTTPクライアントがHTTPサーバにTCPで接続し、以下のフォーマットでリクエストを送り
AWS LambdaとDynamoDBがこんなにツライ時代ではない - めもおきば
ありがたいことに、3年前に#ssmjp 2017/06で話したスライド AWS LambdaとDynamoDBがこんなにツライはずがない #ssmjp をTwitterで紹介して頂いた*1 ようで、当時から大幅に改善しているところを振り返りたいと思います。あと、ついでに最近やっているAzureに関しても少し触れていきます。 サーバーレスアーキテクチャ #とは 当時はこう説明したのですが、今でもそんなに悪くない表現かなと思います。 書籍は現在「Serverlessを支える技術 第3版」まで出ていますので、BOOTHからどうぞ（隙あらばダイマしていく方針）。 サーバーレス三種の神器 今このスライドを作るなら、認証認可の話を入れるかなと思います。システム内のAWS IAMとクライアント側のCognitoどちらも重要です。 ちなみにAzureを含めておさらいすると、こんな感じの対応になります。 勝
「サーバーレス」の次の段階に進むためのキーワード - めもおきば
この記事は、Serverless Advent Calendar 2019の23日目の記事です。 adventar.org Serverlessというキーワードが登場*1して7年、Google App Engine Preview*2から11年、AWS Lambda*3から5年、みなさんサーバーレスしてますか？ FaaS(Function-as-a-Service)を中心としたサーバーレスなシステム開発事例はいよいよ普及フェーズに入ってきたところですが、その一方でステートレス性などプログラミングモデルとしての制約の厳しさなど課題が多くあることも事実です。というわけで、「サーバーレス」という技術ムーブメントで次の段階に進むためのキーワードをいくつか紹介します。 Stateful FaaS ソフトウェア実行基盤として、プロセス上のメモリやサーバ上のファイルシステム上のデータを永続化しない*4、
Dockerのログ出力先 - めもおきば
ツイートしてて自己完結してしまったので記録のために。 あーそういや今更だけど、stdoutとstderrはまとめてlogging driverに渡されちゃうのか。どちらなのかはdriverには渡っているのでfluentdに出せばラベル付いてるので、ログのことだけ考えれば仕組み的にはどちらに出しても扱うこと自体には問題が無さそう。 — Aki (@nekoruri) June 22, 2019 デーモンアプリケーションで想定外のエラーが出うるのであれば、構造化ログをstdoutという分離は全然ありうると思う。 — Aki (@nekoruri) June 22, 2019 でもそうしちゃうとエコシステムから外れちゃうので、やっぱり最大公約数としてはparseableなテキストでstdout/stderrかなあという気がしてきた。やはりDockerにfile descripterの概念が欲しい
もう「サーバーレスだけどサーバあるじゃん」という話をしたくない - めもおきば
3年ぐらい同じ事を言い続けてるんだけど、そもそもサーバーレスという言葉の由来はソフトウェアアーキテクチャの話*1。 一つのタスクの実行期間を超えて、ファイルシステムやメモリ上の変数などサーバ固有のリソースに依存しないという、12 Factor Appから死ぬほど言われ続けている制約を満たすプログラミングモデルがサーバーレスの本質です。この制約に視点を置くとサーバーレスとしか言いようがない。 これを真面目にやろうとすると、キューやPub/Subによる非同期タスク（イベント駆動）が必要になってきます。これを整理したのがリアクティブシステム、わかりやすく関数という枠にはめたのがAWS LambdaをはじめとするFaaSです。 その一方で、これを満たしたソフトウェアは、AWSなりAzureなりGCPなりクラウド基盤側が勝手にサーバを増やしたり減らしたりできて、完全従量制にできたりメリットがたくさん
パスポートと公開鍵の議論ポイント - めもおきば
www.osstech.co.jp この記事をきっかけに公開鍵暗号やPKIの在り方について議論が盛り上がってるので、ポイントになりそうな話をまとめてみます。 パスポートにおける公開鍵暗号のおさらい 上の記事を読んでください、という感じなのですが、ざっくりまとめると以下の仕組みです。 ・ICカードにアクセスするためのBasic Access Control：いわゆるPINとかに相当します。「パスポート番号 + 生年月日 + パスポートの有効期限」とのことなので、要するにパスポートの顔写真のページを見た人ならば分かる情報です。 ・データの電子署名を確認するPassive Authentication：Basic Access Controlを通ると、券面のデータ及び、そのハッシュ値：SOD(Security Obeject Document)、SODに対する電子署名が取得できます。この電子署名
技術書典3にて「Serverlessを支える技術」を頒布します - めもおきば
今週末10/22に開催される技術書典3にサークル「めもおきば」として参加します。 techbookfest.org 以前から出る出る詐欺が続いていた「サーバーレスの厚い本」を、 新刊「Serverlessを支える技術」として1000円にて頒布します。 ※表紙込み全60ページ、既刊の内容も含みます。 また、以下の既刊も合わせて持ち込みます。 TechReport 2015.12 (C89) Hardening 体験記／クラウド四方山話／2015年振り返りと2016年予想 TechReport 2016.12 (C91) 2016年振り返りと2017年予想 TechReport 2016.08 (C92) SORACOM／セキュリティ・キャンプ／Bluetooth mesh 以前の「サーバーレスの薄い本」についても若干数あるので、（居ないとは思いますが）欲しい方は声を掛けてください。 それでは
Linuxのうるう秒おさらい - めもおきば
7/1 午前9時(JST)にうるう秒が挿入されますが、注意すべきポイントのおさらいです。 うるう秒って何よ NICTの資料の先頭7ページ目まで読んでください。 ざっくり言うと、現在の時計というのは「原子時計」が基準になっています。太陽の周りを回る公転周期に合わせて微調整するのがうるう年で、地球自体が回転する自転時間に合わせて微調整するのがうるう秒です。 現象としては、「月末」の日付が変わる直前に1秒追加されます。ただし、これはUTC(協定世界時)での話なので、日本標準時では9時間の時差があるので朝9時(の直前)になるわけです。 時間の進みを表にするとこんな感じです。 UTC(協定世界時) JST(日本標準時) うるう秒を知らない時計 2015年 6月30日 23時59分57秒 2015年 7月 1日 8時59分57秒 2015年 7月 1日 8時59分57秒 2015年 6月30日 23時
2016年のサーバレスアーキテクチャ総まとめ - めもおきば
この記事は、Serverless Advent Calendar 2016の16日分(だったはずのもの)です。 なんとかクリスマスまでには間に合ったのでお許しくださいorz まとめ AWS Lambdaの功罪で混在されがちな概念が整理されて議論されるようになった 提供されるBaaSのみを使ってリッチアプリケーションを開発する手法 フルマネージドなFaaSの実行環境 高水準コンポーネントをイベントで接続するリアクティブシステム 主要各社のFaaS実行環境が揃ってきた AWS Lambda Azure Functions (2016-11-15 GA!) IBM OpenWhisk (2016-12-14 GA! おめでとうございます!) Google Cloud Functions (2016-02-13 Alpha) 国内のニフティクラウドからも サーバレスアーキテクチャにまつわる様々な動
「通信の最適化」の論点 - めもおきば
論点書き出してみたけど多すぎて超絶カオス。 現状発生している実害 チェックサム比較の失敗(発端) 画質の劣化 exif等メタデータ削除による情報欠損 元ファイルよりサイズが増える 技術的詳細が非公開 「最適化」という単語の是非 オプトインとオプトアウト 送信者(コンテンツ提供者)の同意 自衛のために全HTTPS化することで、かえってトラフィック増える問題 HTTPS化による計算機コスト、ファイル改竄による不具合対応のリスクの負担 サービス内容の意図しない/再現が難しい劣化*1 受信者の財産権の侵害とも言える。 受信者(顧客)の同意 消費者保護観点からより深い内容周知の上での同意が必要では無いか オプトアウトが可能かどうか ISPとしてのサービスが土管であるべきか否か 例えば、可逆圧縮での再圧縮なら良かったのかどうか 携帯キャリアが提供しているのは「インターネット」サービスかどうか iモード
うるう秒まとめ - めもおきば
今年は、2015/07/01 08:59:60 JST としてうるう秒が挿入されます！(うるう秒実施日一覧) 「うるう秒なんてきちんと処理したくない」という人向けのまとめ。 まとめっぽい記事 7/1の閏秒を迎えるにあたってLinuxでは何をすべきか？ TECHNICAL ASPECTS OF LEAP SECOND PROPAGATION AND EVALUATION うるう秒の問題（Windows、SQL Server、MySQL、.NET Framework） NICT うるう秒実施に関する説明会: うるう秒説明資料 【レポート】2015年7月1日実施のうるう秒についての説明会 (NVS) AWS AWS側コンポーネント: 前後12時間ずつ、計24時間かけて調整する。 EC2: ntp.orgとか自前管理(共有責任モデル)、デフォルトだとntp.org/time.windows.com
glibcを更新しても大丈夫な「正しい」タイムゾーンの設定方法 (2/3追記あり) - めもおきば
RHEL, CentOS, Amazon Linux (6以前) /etc/localtime を /usr/share/zoneinfo 以下から上書きしたりシンボリックリンク張ったりという手法が横行していますが、 /etc/localtime は glibc パッケージに含まれるためパッケージを更新すると上書きされてESTとかに戻ってしまうわけです。 当然ながら、ディストリビューションとして正しい設定方法が用意されているので、こちらを使います。 /etc/sysconfig/clock にタイムゾーンを書きます。*1sudo sed -i -e "s/^ZONE/#ZONE/g" -e "1i ZONE=\"Asia/Tokyo\"" /etc/sysconfig/clock tzdata-update を実行します。sudo /usr/sbin/tzdata-update これだけで
ウェブアプリにおけるBash脆弱性の即死条件 #ShellShock - めもおきば
条件1. /bin/shの実体がbashのディストリビューション RHEL CentOS Scientific Linux Fedora Amazon Linux openSUSE Arch Linux (自ら設定した場合: Debian, Ubuntu) 条件2. 動作環境 CGI (レンタルサーバでありがちなCGIモードのPHP等も含む) Passenger(Ruby) 条件3. プログラム内容 Passengerは全死亡 *1 systemや `command`、 '| /usr/lib/sendmail' などで外部コマンド実行 *2 PHPのmailやmb_send_mail、その他フレームワーク等を介したメール送信 *3 以下は条件1が不要 明示的にbashを呼ぶ 先頭で #!/bin/bash や #!/usr/bin/env bash しているプログラムを実行 (rbenv
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
