【Go】HTTPサーバーは安全に終了させましょう
はじめに こんにちは。都内でソフトウェアエンジニアをしているtomoriです。 突然ですが、Go言語でHTTPサーバーを実装する際、サーバーの終了処理を適切に実装できている自信はありますか？ 自分が開発に携わっているプロダクトでは、ほんの最近まで下記のような不適切な終了処理を行なっていました（話を簡単にするためにここでは panic を使っています）。 err := http.ListenAndServe(":8080", handler) if err != nil { panic(err) } HTTPサーバー実装のサンプルとかでよく見るやつですね。 これだとアプリケーション側で、いわゆる Graceful Shutdown ができておらず、実行環境にて不具合を引き起こす恐れがあります。 というわけで、最近それを修正したのでアウトプットとして記事にします。 Go言語でHTTPサーバーを
新Linuxカーネル解読室 - ソケットインターフェース(データ構造と概要編) - VA Linux エンジニアブログ
「Linuxカーネル2.6解読室」（以降、旧版）出版後、Linuxには多くの機能が追加され、エンタープライズ領域をはじめとする様々な場所で使われるようになりました。 それに伴いコードが肥大かつ複雑化し、多くのエンジニアにとって解読不能なブラックボックスとなっています。 世界中のトップエンジニア達の傑作であるLinuxカーネルにメスを入れ、ブラックボックスをこじ開けて、時に好奇心の赴くままにカーネルの世界を解読する「新Linuxカーネル解読室」プロジェクト。 本稿では、旧版第21章で解説されていたソケットインターフェースについて、カーネルv6.8のコードをベースに主にデータ構造を中心に解説します。 はじめに ソケットの実体と概要 ソケット操作関数の実装 ファイル操作関数によるソケット操作の実装 次回予告: ソケット生成編 執筆者 : 須田 哲志、稲葉 貴昭 ※ 「新Linuxカーネル解読室」
コンテナの仕組みを勉強したかったため、Goでコンテナランタイムを自作した。雑実装だし未実装の機能もたくさんあるが、ある程度形になってきたため現状をまとめる。 リポジトリ github.com kombu/dashi - 自作コンテナランタイム kombu/nimono - eBPFを利用したシステムコールロガー kombu/yaminabe - dashiとnimonoを利用したマルウェアサンドボックス プロジェクト名から和の雰囲気を感じるが、これはリポジトリ名をkombu（昆布）にしたかったため、せっかくなら今回は和風で固めようと思ったから。趣があっていいんじゃないでしょうか。 dashiが自作コンテナランタイムだが、nimonoとyaminabeは実験的な要素で、セキュキャン2023でコンテナを使ったマルウェアサンドボックスを実装した経験があり、今回はその再実装を自作コンテナランタイム
こんにちは。 GMO NIKKOのT.Cです。 今回は、Dataflowで、特定のゾーンにあるリソースが一時的な不足(= ZONE_RESOURCE_POOL_EXHAUSTED)により、間欠的にJobが失敗した内容について話したいと思います。 ※ 本ブログで発信される情報は、個人の見解でドキュメントで直接言及されてない内容も含まれているため、実際とは異なる可能性もあるので、参考までにしてください 1日何回も、Cloud FunctionでDataflow(batch・dataflow shuffle)を動かしてGCSにあるログを処理していますが、ゾーンのリソース不足により、Jobが失敗する現象が数日にわたって間欠的に発生していました。 Startup of the worker pool in zone us-central1-a failed to bring up any of th
Competitiveness is a vice of mine. When I heard that a friend got Linux to boot off of NFS, I had to one-up her. I had to prove that I could create something harder, something better, faster, stronger. Like all good projects, this began with an Idea. My mind reached out and grabbed wispy tendrils from the æther, forcing the disparate concepts to coalesce. The Mass gained weight in my hands, and a
This blog post is adapted from a talk that Adam Hess and I gave at RubyKaigi 2024. Until recently, Ruby lacked a mechanism for detecting native-level memory leaks from within Ruby and native gems. This was because, when Ruby terminates, it does not free the objects that are still alive or the memory used by Ruby’s virtual machine. This is because the system will reclaim all the memory used anyway,
AWS ECS で実行するバッチ処理を Cluster Auto Scaling を使ってコスト最適化する - Hatena Developer Blog
システムプラットフォームチームで SRE をしている id:chaya2z です。 この記事は、はてなの SRE が毎月交代で書いている SRE 連載の6月号です。先月は id:MysticDoll さんの Postfixのログ監視で注意すべきSMTPのステータス仕様について でした。 ECS で実行するバッチ処理を、インスタンス数を最適化する仕組みである ECS Cluster Auto Scaling を使ってコスト最適化した取り組みを紹介します。 ECS の起動タイプに EC2 を使う背景 はてなでは、ECS の起動タイプとして Fargate ではなく EC2 を使用しているサービスがあります。そのサービス例として、バッチ処理があります。バッチ処理のジョブには数秒・数分で終わるものもあれば、数時間かかるものがあります。 EC2 起動タイプを選ぶ理由は、タスク終了までのタイムアウト待
CloudShell VPC environment から VPC内のEC2インスタンスやRDS DBインスタンスに接続してみた | DevelopersIO
CloudShell VPC environment から VPC内のEC2インスタンスやRDS DBインスタンスに接続してみた もっと簡単にVPC内のリソースにアクセスしたい こんにちは、のんピ(@non____97)です。 皆さんはもっと簡単にVPC内のリソースにアクセスしたいと思ったことはありますか? 私はあります。 VPC上のRDS DBインスタンスやRedisクラスターなどのリソースに接続したい場合、Site-to-Site VPNやClient VPN、Direct Connectがなければ踏み台が必要になります。 踏み台へのアクセス方法は以下のようなものがあります。 直接SSH SSMセッションマネージャー EC2 Instance Connect SSMセッションマネージャーとEC2 Instance Connectについては以下記事をご覧ください。 しかし、上述のいずれの
えっと、なんかヤバそうなやつが来ました。 クラウドエース株式会社様からも注意喚起されているOpenSSHの脆弱性についてです。 本編 当方はGCE(ubuntu)で複数サーバを運用しており、以下手順でアップグレードしました。 cd ~ # 現在のバージョン確認 ssh -V # 〜4.4p1であるか、8.5p1〜9.7p1なら以下対応が必要 # アップグレードの準備 sudo apt-get update sudo apt-get install -y aptitude sudo aptitude install -y build-essential zlib1g-dev libssl-dev libpam0g-dev libselinux1-dev libkrb5-dev sudo mkdir /var/lib/sshd && sudo chmod -R 700 /var/lib/ssh
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
コンテナランタイムを自作した - zebian.log
Dataflow(batch)でZONE_RESOURCE_POOL_EXHAUSTEDが発生した話
Booting Linux off of Google Drive
Finding Memory Leaks in the Ruby Ecosystem
OpenSSHのヤバそうな脆弱性に対応する【Ubuntu編】