前回は、Bicepの性質から、どのような基本設計でIaCを指向するか書きました。 https://tech.guitarrapc.com/entry/2021/07/15/033715 今回は、実際にBicep Resourceを使って書くときに、どのような工夫が必要なのかメモしておきます。 概要 Bicep Resource Preview リソースと ARM Template Previewページは手薄 Bicep Module 粒度 Bicep Parameter string, int, bool の扱いやすさ object型の型宣言が弱い array 型の型宣言が弱い 実行時Parameter の渡し方 existing と リソースの存在保障 existing の実行成功は存在保障ではない Role Name の取得 Built-in Role Custom Role 来てほし
SREの本田（@mov_vc）です。 Kaizen Platformではインフラ構築にPulumiを採用し始めています。今回は、Pulumiの基本的な説明+ECS環境をPulumiで構築した手順をまとめました。結論から言うとPulumi、かなり便利なので、導入を考えているよ〜という人はぜひ読んでみてください。 TL;DR 汎用言語で書ける TypeScript, JavaScript, Pythonで記述できます。 依存関係解決してくれる リソース間に依存関係があってもPulumiさんがよしなにやってくれます。 WebUIやべーじゃん WebUIはこんな感じでプロジェクト、環境一覧画面があり、イケてます。 作業履歴とかもWebUIで確認できる 環境ごとのstate情報、Pulumi作業履歴などが確認できます。 開発めっちゃ活発 リリースサイクルが週1ペース。ちゃんと寝てる？？？ ぷ…Pul
みなさん、こんにちは。まつもとりーのインフラ入門第六回です。 本連載では、主にインターネット基盤技術、または、インターネットのインフラ技術と呼ばれる領域に関して、Webホスティングサービスの歴史やWebサーバの設計と実装を中心に執筆していくと第一回で述べました。 第六回では、高集積マルチテナント環境において非常に重要で、かつ、とてもおもしろいセキュリティの研究動向についての研究動向を紹介します。 まつもとりーのインフラ入門－第五回「高集積マルチテナントアーキテクチャのリソース分離（2）」 まつもとりーのインフラ入門－第四回「高集積マルチテナントアーキテクチャのリソース分離（１）」 まつもとりーのインフラ入門－第三回 「WebサーバとWebホスティングシステム(2)」 まつもとりーのインフラ入門－第二回 「WebサーバとWebホスティングシステム」 まつもとりーのインフラ入門－序章「インフラ
みなさん、こんにちは。まつもとりーのインフラ入門第二回です。 本連載では、主にインターネット基盤技術、または、インターネットのインフラ技術と呼ばれる領域に関して執筆していくと前回述べました。 そこで、第二回では古くからあるWebホスティングサービス、または、レンタルサーバと呼ばれるサービスについて、Webサーバの観点からどのような技術的取り組みがなされてきたかを紹介します。 本記事を通じて、Webホスティングサービスのように古くから提供され、長い間改善が積み重ねられてきたサービスの構成や設計から、WebサーバやOSに関する基礎的でありながら実践的な知識を習得頂ければ幸いです。 みなさま、はじめまして。さくらインターネット研究所で主にインターネット基盤技術を中心に研究開発をしているまつもとりーと申します。 本連載では、主にインターネット基盤技術、または、インターネットのインフラ技術と呼ばれる
聞きながら書いてたので抜けてたり誤字とか多いと思う。各々の資料はあとで公開されるはず。Twitter のハッシュタグは #ゲームサーバ勉強会 なお、会場内からも発表されてましたが、第二回の開催も検討とのことです。 皆さまご来場ありがとうございました。懇親会で話しましたが、好評いただいたので、第2回やる方向で検討します。次回予告イメージとしては、10月頃、負荷試験、うどんの会による自家製うどん。 #ゲームサーバ勉強会 — 元イカ2 (@seizans) August 3, 2018 アカツキ: 失敗から学ぶ・大規模環境における Ruby on Rails on AWS の最適化 めっちゃ鳥肌 これ、正月かな......#ゲームサーバ勉強会 pic.twitter.com/RKARkr3F5f — 紫苑 (@grwth1009) 2018年8月3日 Rubyはsmallスタートむき#ゲームサー
今回は、Webサーバの実装に依存することなく、OSレイヤでWebサーバソフトウェアが起動時に実行するであろうシステムコールを監視して、そのタイミングでプロセスをイメージ化する方法（PoC）について紹介します。 その前に、まずは前提の一致ということで、僕は以前から、Webサーバプロセスの性質について、プロアクティブ性とリアクティブ性という分類について述べてきました。 プロアクティブ性とリアクティブ性について簡単にまとめると、以下のようになります。 Webサーバ機能のプロアクティブ性とリアクティブ性 突発的なアクセス集中のような変化に耐えうるシステムを構築するためには，負荷の状態に基いて適切なインスタンスの数を決定し，必要以上にコンピュータリソースを使用しないように設計することも重要である． 単一のサーバに高集積にホストが収容可能であり，ホスト単位でのリソース管理を適切に行いながら，セキュリテ
試したいから、作る。ghq、goreの作者motemenの開発は「自分本位」で駆動する 次々とOSSを送り出す株式会社はてなのCTO、大坪弘尚さん。連続開発を支える、発想の源、そしてモチベーションをご本人に伺いました。 エンジニアにとっての強みとは何でしょうか。その答えはさまざまですが、「プロダクトを完成させるスピード」という要素は、“強み”の一つの指標と考えていいでしょう。 「エンジニアの会社」として見られることの多い株式会社はてなの中でも特に「作るスピードが早い」と一目置かれる人物がいます。CTOの大坪弘尚（おおつぼ・ひろなお／ @motemen ）さんです。 大坪さんはghqというツールを20代で公開し、コミュニティから高い評価を受けました。それにとどまらず、GoにおけるREPLを実現するツール、goreも続けてリリースし、GitHubで2000以上のスターを獲得しています。常にオー
インフラエンジニアの多分、華形のお仕事の１つであるミドルウェアの性能検証を久々にガッツリやる機会がありましたので、検証作業の基本的な項目について初心から振り返っておきたいと思います。読みやすさ度外視の詰め込み記事注意警報です。 世の中、雑な検証結果もちょいちょい散乱していて、私自身もそうならないよう注意を払っているわけですが、ガチでやると気をつける項目が多くて、自分で忘れたりしないようにと、誰かにやってもらいたい時に基本を抑えてから取り掛かってもらうために、形にして残しておこうと思った次第であります。 目次 なぜ性能検証をするのか 環境の準備 インスタンスの用意 クライアントの用意 サーバーの用意 ボトルネックになりうる項目 CPU Utilization Memory Network Bandwidth Disk Bandwidth Disk IOPS Disk Latency Disk
サービスの一時的な飢餓状態とはどういう状態か。その上で、とあるインスタンスが古いインスタンスのリソースを奪い、自身に吸収することによってとあるインスタンスはある種リソースを蓄積する。しかし飢餓状態が長く続くとその循環が起こり続け、いつかインスタンスは少数になりサービスは停止する。— 松本 亮介 / まつもとりー (@matsumotory) 2017年9月29日 こんなことを以前から考えていました。 生命の個体を維持するために非常に重要な役割を果たしているとされているオートファジーという機能があります。まずは以下のようにWikipediaの解説を見てみましょう。 オートファジー (Autophagy) は、細胞が持っている、細胞内のタンパク質を分解するための仕組みの一つ。自食（じしょく）とも呼ばれる。酵母からヒトにいたるまでの真核生物に見られる機構であり、細胞内での異常なタンパク質の蓄積を
この文章は、サーバサイドのウェブアプリケーション開発において、社内実績の少ない新しい言語を採用したときにインフラ面で考慮したことを社内向けにまとめたものです。 はてなでは、長らくPerlでウェブアプリケーション開発を続けてきた一方、ここ数年で社内でScalaまたはGoの採用事例も増えてきました。 今後開発が始まるプロダクトにおいても、Perl、Scala、Goもしくは他の言語を採用するかどうかを開発開始時に選ぶことになるでしょう。 新言語を採用するときに、考慮すべきことの一つとして、「インフラ」への影響があります。 新言語に関する雑談をしていると、ウェブアプリケーションエンジニアに「インフラ」への影響について聞かれます。 もしくは、ウェブオペレーションエンジニアから考慮するポイントを伝えることもあります。 ScalaやGo以外に、Node.jsやサーバサイドSwiftはどうかというのも雑談
主にアプリケーション開発者向けに、Linuxサーバ上の問題を調査するために、ウェブオペレーションエンジニアとして日常的にやっていることを紹介します。 とりあえず調べたことを羅列しているのではなく、本当に自分が現場で使っているものだけに情報を絞っています。 普段使っているけれども、アプリケーション開発者向きではないものはあえて省いています。 MySQLやNginxなど、個別のミドルウェアに限定したノウハウについては書いていません。 ログインしたらまず確認すること 他にログインしている人がいるか確認（w） サーバの稼働時間の確認 (uptime) プロセスツリーをみる (ps) NICやIPアドレスの確認 (ip) ファイルシステムの確認（df） 負荷状況確認 top iostat netstat / ss ログ調査 /var/log/messages or /var/log/syslog /
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
