サーバーレスの次はなんなんだ
はじめに この記事は、同人誌サークル「めもおきば」から不定期刊行している技術解説本「めもおきばTecReport」に書いたものを公開用に再編集したものです。 ⇒ めもおきばTecReport 2023.12 この記事のほかにも「私もSecHack365に参加したい！」や、「2023年振り返りと2024年技術予想」としてこんなキーワードを取り上げているので、気になったらぽちっとしてください！ メガクラウドと特化型クラウド／ハイパーバイザーのSoC化／ライセンスとクラウドベンダー／イベント駆動型API／LLM時代のAIペアプロ力／生活必需品としてのGPU・NPU／Passkey／ウェブアクセシビリティ／リアルイベントの再開 サーバーレスの次はなんなんだ サーバーレスと呼ばれる技術ムーブメントが盛り上がり始めて8年近くが経ちました。各クラウドベンダーのFaaS（Function-as-a-Ser
運用中のサービスに負荷試験を導入した事例の紹介 - KAYAC engineers' blog
SREチーム(新卒)の市川恭佑です。今回は、Tonamelという自社サービス(Web)において負荷試験を導入した事例を紹介します。 このエントリは「先送りされがちな負荷試験の導入について心理的なハードルを下げる」ことを目的としています。 そのため、事例紹介と銘打っていますが、列挙される事実の独立性よりも文脈性を優先しています。 表現が少し冗長に感じるかもしれませんが、負荷試験について距離感を感じている方は是非お付き合いください。 負荷試験を導入するに至った経緯 Tonamelは、本格的なリリースから5年以上という、比較的長い運用歴を持つサービスです。 まず、何故このタイミングで負荷試験を導入することになったのかについて、その経緯を説明します。 ポストモーテムによる気づき（文化的な土台） 今年の3月に公開されたエントリにもあるように、カヤックでは着実にポストモーテム文化が浸透しつつあります。
OAuth認証とは何か?なぜダメなのか - 2020冬 - r-weblife
こんばんは。ritouです。 Digital Identity技術勉強会 #iddance Advent Calendar 2020 1日めの記事です。 qiita.com 初日なのでゆるふわな話をしましょう。 何の話か もうだいぶ前ですね。9月のお話です。こんなTweetを見かけました。 社内Slackにいる「OAuth認証」と書くと訂正してくれるbotが丁寧な解説をするようになっていた 認証(Authentication)と認可(Authorization)は間違えやすいわりにミスると甚大な被害をもたらしがちなので、常日頃から意識を高めていきたいですね pic.twitter.com/oVQxBgZcHS— greenspa (@greenspa) 2020年9月28日 このbotに対する思うところはもう良いです。 今回は、「OAuthの仕様に沿ってID連携を実装するいわゆる"OAut
キャッシングの課題と戦略
Amazon で長年にわたってサービスを構築してきた中で、新しいサービスを構築するけれども、このサービスはそのリクエストを満たすためにいくつかのネットワーク呼び出しを行う必要があるというシナリオのさまざまなバージョンを経験してきました。おそらく、この呼び出しは、リレーショナルデータベース、Amazon DynamoDB などの AWS のサービス、または別の内部サービスに対するものです。単純なテストまたは低リクエストレートでは、サービスはうまく機能しますが、問題もあることにも気付きました。問題は、この他のサービスへの呼び出しが遅いこと、または呼び出し量が増えるとデータベースのスケールアウトに費用がかかることです。また、多くのリクエストが同じダウンストリームリソースまたは同じクエリ結果を使用していることに気づいたため、このデータをキャッシュすることが問題の解決策になると考えています。キャッシ
自作サービスがDDoS攻撃された話 - 週休７日で働きたい
攻撃に立ち向かうイヌさんThe English version is available here. タイトル訂正: 「自作サービス『に』→『が』DDoS攻撃された話」「それはDDoSではない」という指摘に関して末尾に追記 (6/18)SaaSを開発していると本当にいろんな事が起こります。それらは時に開発者に喜びや悲しみ、怒り、感謝、落胆や興奮をくれます。思い返してみれば結局はみんないい思い出になるものです。先週末に、拙作の小さなウェブサービスがDDoS攻撃を受けました。言わずもがな、悪い出来事です。本稿ではこの事故がどんなものだったのか、どうやって対処したのかについてお話します。 どうもTAKUYAです。僕はInkdropというクロスプラットフォームなMarkdownノートアプリを独りで3年以上開発・運用しています。ユーザ数2万人以下のとてもニッチなSaaSで、僕はこのサービスで生計を立
自社 OSS のコミュニティ運用を Discord に集約した
自社の OSS と無料サービスのコミュニティをすべて Discord に集約しました。かなりうまく回っていると思っているので、どんな感じで運用しているかを書いていきます。 前提IT 系パッケージメーカーな零細企業クローズド自社製品で食べているOSS へのサポートは提供していない無料サービスへのサポートは提供していないOSS へは積極的に投資しているロードマップにある機能を有償で前倒して実装することもあるコミュニティマネージャーの採用信頼できる技術者に副業としてコミュニティマネージャーをお願いしています。 仕事内容は責任はなく、基本的には誰かがチャットをしたときに反応をしてもらうというものです。質問しやすい空気を作ってもらっています。 また、コミュニティマネージ以外に検証の仕事も合わせてお願いしているます、そのため OSS やサービスをユーザ視点で触っており、技術もわかるコミュニティマネージ
焼肉サブスクの脆弱性 - Qiita
※規約違反として限定公開にされました。Qiita運営からのメールに「Qiitaだけじゃなくて他サービスの規約違反もあかんのやで」という文言があったので、そのへんに気をつけて修正しました。 本記事はすべてフィクションです。実在する企業とは一切関係ありません 焼肉サブスクに２２日通った。 その中で、色々な脆弱性が見受けられたため、詳しく書く。 ※この記事で紹介する脆弱性を実際に突いてサービスを不正利用すると、詐欺罪に問われる可能性があるので、絶対にやらないこと。また、この記事は啓蒙を目的としており、システムの悪用を推奨していない。 焼肉サブスクのシステム サブスクプラットフォームに登録し、クレカでサブスクパスに課金する。 店でパスの画面を見せる。画面には１日１回だけ押せるボタンがあり、ボタンを店員の目の前で押すことで、サービス権を行使する。食べ放題が無料になる 最後にレジで会計するが、食べ放題
NoOpsを実現するSREの存在意義と役割
NoOps Meetup #6 （ https://noops.connpass.com/event/131553/ ） でお話した内容です。スタディストのSREチームは、サービス運用やToilに関係する作業時間は、週のうち5%〜10%程度に維持しています。ここに至るまでのスタディストの実践例を、SREのプラクティスを交えてお話しました。
JVNVU#98433488: HTTP/2 の実装に対するサービス運用妨害 (DoS) 攻撃手法
HTTP/2 通信の処理は、HTTP/1.1 通信の処理と比較して多くのリソースが必要であり、RFC7540 の Security Considerations セクションにおいても、サービス運用妨害 (DoS) 状態に関する検討が行われています(10.5. Denial-of-Service Considerations)。しかし、どのように対策すべきかは実装者にまかされており、これが以下の問題につながっています。 Data Dribble - CVE-2019-9511 攻撃者は複数のストリームを通じて大きなサイズのデータをリクエストし、ウィンドウサイズやストリームの優先順位を操作して、データが 1 バイト単位で処理されるように仕向けます。これらのデータを効率的に処理できなければ、CPU, メモリ、もしくはその両方が大量に消費され、サービス運用妨害 (DoS) 状態が引き起こされる可能
「運用エンジニア不要論」は誤り、グーグルが提唱した新概念に注目
今回は「ITインフラの運用は自動化が進む」という定説と、運用エンジニアのキャリアを再考する。 ここ数年、ITインフラ技術が進歩し、それに伴って運用エンジニアの仕事が様変わりしている。最も大きなITインフラの変化はパブリッククラウドの普及だ。仮想環境が当たり前のように使われるようになり、ITインフラの設定や管理をソフトウエアで定義できるようになった。例えば、仮想マシン（VM）の起動、ネットワークの設定などである。 設定作業をソフトで実行できるため、自動化できる運用作業が増えた。インフラストラクチャー・アズ・コード（Infrastructure as Code）と呼ばれるトレンドだ。以前のように、パスやコマンドを間違えないように注意しながら、手順書に沿って手作業で設定する仕事は大幅に減った。 運用業務がソフトで実行できるようになると、アプリケーション開発者が運用作業の一部を担当できるようになる
[レポート] #ssmjp 2019/03 〜ヤマサキ春のサメまつり〜 で「運用自動化とは」を聞いてきた | DevelopersIO
はじめに 先月（3月）の 6日に、「ヤマサキ春のサメまつり」と題して開催された #ssmjp 2019/03 。その名の通り JAWS DAYS 2019 の裏話からチョウザメまで様々な「サメ」にまつわるプレゼンテーションが行われたのですが、その中でいちばんアウェイ感の高かった（主観）「運用自動化」の話が個人的に非常に興味深かったので、個人的に重要と思ったところを中心にご紹介します（一ヶ月近く時間が空いてしまいましたがご容赦下さい…）。 #ssmjp 2019/03 - connpass 話者は、 2017 年に有名な 運用自動化、不都合な真実 のプレゼンを行って以来 「不都合」のハタノさん と呼ばれ、今年（2019年）は 正しい「運用自動化」の考え方を広める人（に私はなりたい） と公言されている @tcsh （波田野）さんです。 （画像は JAWS DAYS 2019 「AWS CLIで
![[レポート] #ssmjp 2019/03 〜ヤマサキ春のサメまつり〜 で「運用自動化とは」を聞いてきた | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/eb4b03fb0ebb07671dcd7a3c75fbb048bccfb367/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2019%2F04%2Fssmjp-operation-what-automation_eyecatch.jpg)
コンテナを利用したWebサービス開発と実運用
はてな×さくらが考えるテクノロジーの未来〜コンテナ・分散型データセンター〜 Mar 20th, 2019 Profile id: Songmu (ソンムー) Masayuki Matsuki / 松木雅幸 おそらくはそれさえも平凡な日々 http://www.songmu.jp/riji/ https://metacpan.org/author/SONGMU はてな東京オフィス チーフエンジニア Mackerel プロダクトマネージャー 60+ CPAN Modules 3 Times ISUCON Winner Using Perl YAPC::Tokyo 2019 ベストスピーカー 最近はGoが好き
運用監視サービスのDatadogが、フロントエンド自動テスト「Madumbo」を買収。サーバからフロントエンドまでをモニタリングするフルスタックな監視サービスに
運用監視サービスのDatadogが、フロントエンド自動テスト「Madumbo」を買収。サーバからフロントエンドまでをモニタリングするフルスタックな監視サービスに システムの運用監視をクラウドサービスとして提供しているDatadogは、フロントエンドの自動テストツールを提供している「Madumbo」の買収を発表しました。 Datadogは一般的な運用監視ツールと同様にサーバの稼働状況をモニタリングし異常を発見することに加え、ダッシュボード上でモニタリング状況を見ながら関係者とチャット画面でコミュニケーションできる機能を提供しているのが特徴の1つ。 ApacheやNginx、MySQLやPostgreSQLなど多くのミドルウェア、仮想マシンやクラウドのインスタンス、Dockerコンテナなどの状況も監視可能。 さらにPython、Go、Rubyなどで記述されたアプリケーションやフレームワークを検
公開NTPサービス | 福岡大学情報基盤センター
この公開NTPサービスは、近い将来停止します。本サービスをご利用の方は、設定の変更をお願いします。 English version ニュース 2022年2月17日 学術情報ネットワーク（SINET）回線切り替え工事のため、下記の期間サービスを停止します。停止時間は、多少前後することがあります。 サービス停止時間： 2022年3月13日(日) 午後5時より 午後6時 までの間で約30分程度 2021年3月24日 公開NTPサービスのネットワークを、AS18148からAS63785に切り替えました。 2021年1月12日 キャンパスネットワーク安定運用のため、公開NTPサービス専用のAS番号を取得しました。番号は、63785です。 2020年8月3日 メンテナンスのため、下記の期間サービスを停止します。停止時間は、多少前後することがあります。 サービス停止時間： 2020年8月5日(水) 午後
LINEのMySQL運用について 修正版
Dapr × Kubernetes ではじめるポータブルなマイクロサービス（CloudNative Days Tokyo 2020講演資料）
運用担当者のためのAWS改善マップ | DevelopersIO
Trusted Advisor AWS Trusted Advisorは、コスト、パフォーマンス、セキュリティ、耐障害性、サービスの制限について、アドバイスしてくれるサービスです。 サポートプランによって、チェック項目が異なります。 セキュリティについては、セキュリティグループの無制限アクセス、S3バケット許可などをチェックしてくれます。 セキュリティについては、赤の指摘項目は0にしましょう。 insightwatch insightwatchは、弊社が提供するサービスです。 AWSアカウントが、ガイドラインに沿ったセキュリティのベストプラクティスで運用されているかチェックします。 複数アカウントをチェックしやすいため、たくさんのアカウントを運用されているかたに特にお勧めします。 どなたでも無料でご利用いただけます。 IAMの見直し、定義 IAM のベストプラクティスに基づいた見直しを行い
小中規模のIT系企業における技術的選択と雇用戦略に関する雑感 - たごもりすメモ
でっかい主語で入ったが、要するに2月にあちこち会社巡りをしたときに感じたことについてつらつら書こう、というのが目的。 特定の会社について書いてもしょうがないので、あれこれ*1回ったうちから少なくとも2〜3ケースで該当するなあ、と思ったことについて書く。特定の1社のみに該当する事項はこのエントリにはひとつも出てきません。 またエントリの主旨からして超上から目線になりますが、どうかご容赦ください。 これから成長が本格化するのでインフラを支えられる人材がほしい 正直に言ってこれが一番多かったパターン。スタートアップ的にサービスを作ってきたがその一方でデプロイや監視などの運用まわりが後手後手になっており、そのあたりを支えられる人物がほしい。 話としてはわかるのだが、気になったのは、これを聞くとき、詳しい内容を突っ込んでみると、どうも実際にはそう困ってはいない、というケースがほとんどだったように思え
クラウド時代は運用が主役
「開発担当者も運用担当者もこれからは『運用』というキーワードが大事になる」。日経コンピュータ11月10日号の特集「創る『運用』」でクラウド時代におけるユーザー企業のシステム運用の姿を追ったところ、こう考えているユーザー企業の情報システム部門が増えてきたことを実感した。 運用が大事になる。そう言っても、ハードウエアが故障したときに修理できるとか、統合運用管理ツールの仕組みに詳しいとか、技術的なことではない。もっと大きく、「運用する」ことを起点にシステム開発やシステム運用を考えましょうということだ。 具体的には次のような流れになるだろう。情報システム部門はサービス提供の手段としてシステムを開発し、運用する。時には外部のクラウドを使う。利用部門にとっては提供元はどこでもよく、適切なシステムを利用できれば事足りる。情報システム部門は、クラウドサービスの利用や自社システムの運用を通じて、サービスの課
第17回 2011年クラウドサービスの適用ドコロ［PART 2］ | gihyo.jp
3月11日、筆者は少し遅めの昼食をとっていました。ちょうど食べ終わる頃に、今まで経験したことのないような強さで、何度も、長時間に渡る揺れを体感しました。急いで職場に戻り、情報を収集し事の重大さを認識しました。 この度の東北地方太平洋沖地震により亡くなられた方々のご冥福をお祈り申し上げますとともに、被災されました皆様、またそのご家族の方々に対しまして心よりお見舞い申し上げます。少しでも早い被災地の復旧・復興を祈念いたします。 インフラエンジニアの対応 さて、このような状態になった場合、インフラエンジニアとしてはどのような対応をすべきか考えます。 データセンターの状況 まずは筆者の場合、オフィスは東京都内（23区内）、データセンターは別の東京都内（23区内）にあり、現地に向かいつつも電話でデータセンターの状況（情報）を入手します。これは、データセンターの受付、オペレータが見ることができる範
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「AWSを活用して少人数で複数のサービスを運用するコツ」〜jawsug in nagoya〜
