[AWS Expert Online for JAWS-UG]AWS SAW を使った�トラブルシューティング�効率化のススメ

PHPerKaigi 2024の登壇資料です。 https://phperkaigi.jp/2024/ - https://speakerdeck.com/moznion/pattern-and-strategy-of-web-application-caching - https://soudai.hatenablog.com/entry/cache-strategy

米ドル/円 が150円と計算しやすくなり、コスト削減の圧力が日々強まる中、皆様お宝探しと垂れ流し回収の真っ最中でございましょうか。 最近はコスト削減や予算について見ることが多いので、その中で出てきた面白げな話に雑談を加えてとりとめなく書いてみようと思います。 削減余地はある 昨年にご好評いただいた AWSコスト削減とリソース管理 | 外道父の匠 を含め色々な削減施策を試みてきましたが、サクッと成果になる箇所から泥沼に動かない所まで様々あったりします。 ただ、どんなアカウントでもトラフィックや処理負荷には波があり、それに対する余剰リソースを確保して構成しているので、その辺をキュッと絞ることまで含めればやれることは必ず一定以上存在することになります。 そういう大きなお宝ではない小さなお宝だと様々あり、古びたとか退職者が作ったとかで、ほぼ使っていない垂れ流しリソースやデータをかき集めれば、チリツ

ガジェット全般、サイエンス、宇宙、音楽、モータースポーツetc... 電気・ネットワーク技術者。実績媒体Engadget日本版, Autoblog日本版, Forbes JAPAN他 エクストリームスポーツを効果的にマーケティングに取り込んできたエナジードリンクのレッドブルが新たに公開したのは、レッドブル・レーシングのF1マシンを世界最速のカメラ搭載ドローンでぴったり追跡する空撮映像です。 F1世界選手権の2024年シーズンは今週末に開幕します。昨シーズンはレッドブル・レーシングF1チームのマックス・フェルスタッペン選手が圧倒的な強さを見せつけて世界チャンピオンの座を防衛し、先頃行われたシーズン前の合同テストでも、圧倒的な安定感とスピードを誇示していました。 そんな自動車レースの頂点に立つレッドブルのF1マシンと世界チャンピオンを追いかけ回すドローンパイロットとして選ばれたのは、Dutch

Stable Diffusion Forgeを表示した様子。基本的な操作は既存のStable Diffusion WebUI AUTOMATIC1111とほぼ同じ 画像生成AI「Stable Diffusion」用の新しいユーザーインターフェース「Forge」が2月6日に登場しました。開発したのは、これまで「Controlnet」や「Fooocus」などStable Diffusion関連の様々な重要技術を開発してきたillyasviel（イリヤスベル）さん。何よりインパクトが大きいのは、グラフィックボードのVRAM容量が小さい安価なPCでも最新版のStable Diffusion XL（SDXL）が動かせることです。 RTX 40シリーズが求められたSDXL SDXLは、2023年8月にStablity AIが発表した画像生成AI。高画質な出力ができる一方、コミュニティーサイトで話題にな

https://enog.jp/archives/2828 ENOG81で発表したスライドです。

SaaS をアーキテクトをするにあたって、どのような事を考えればよいのか？をまとめました。

マルチクラウド展開にまつわる既成概念を覆すより データ転送では、特に長距離の場合にレイテンシ（遅延）が問題になることがありますが、現在はすべてのクラウド・プロバイダーがそれぞれの物理インフラストラクチャを互いの近くに配置（専門用語では「コロケーション」）しているため、これはさほど問題となりません。この近接性（場合によっては同一コロケーション施設内の別の部屋）は、クラウド間のレイテンシがミリ秒単位であることを意味します。それに加え、クラウド・データセンター・リージョンは世界中で増加しており、クラウド・リージョン間の距離は縮まっています。 という事で、レイテンシ(遅延)について、まとめてみてみます。 ■ Agenda レイテンシ(遅延)とスループット(帯域幅) レイテンシと TCP の動作 帯域幅遅延積(Bandwidth-Delay Product) TCP Window Size の調整と

どうもお疲れ様です。MESIです。 これは私が駆け出しの新卒1年目の頃でしょうか。 ある社内のつよつよエンジニアからこう言われました。 「MESIよ。流行りのフレームワークの使い方を覚えるのではなく、土台を理解しなさい」 彼はそう言い残すと1冊の本を残し会社を去っていきました。 これ。 託された本を読んでみたものの当時の私には難しすぎました。 理解ができないのですが、何が理解できないのかがわからない。そんな状態でした。 毎日この本とにらめっこをしましたが、時間だけが過ぎていきました。 大学でコンピュータサイエンスを全く学んでいない状態で入社した当時の私には難しすぎたのです。 私は諦めずにOS関連の低レイヤーの本を読み出しました。そして以下のループにハマりました 本の内容が理解できない ↓ 本を理解するために別の本を読む ↓ 理解できないのでまた別の本を読む いきなり難しい本にチャレンジをし

2024年1月末まで在籍していますが昨年12月に業務は終えていて、いまは有休消化期間中です。2010年から約14年間勤めてきた、自分の生き様そのものとも言えるクックパッドを離れるのには、表現しきれないほど大きく、複雑な思いがあります。 僕がこの14年間でやってきたことを振り返ってみます。 入社 クックパッドに入社した時は新卒3年目相当で、26歳でした。もともと料理と Ruby が好きで、当時まだ珍しかった Ruby on Rails でサービス開発をしているらしいという点や、当時からネットウォッチしていた @ryo_katsuma さんが所属していること、直属の上司の井原さんが転職したことが決め手になり、体当たりで飛び込みました。当時の僕はほとんど実績もなく、入れてもらえるかギリギリのところだったと思いますが、おそらく井原さんが頑張って交渉してくれたのだと思います。本当に感謝しています。こ

当方アラサー女。顔はたぶん可愛い。 4年付き合ってる彼氏との関係でマジで悩んでるので何か変化を起こせるアドバイスがほしい。 私が彼氏に求める条件はただ一つ顔がいいことである。今の彼氏は顔がどタイプで、顔がタイプなら他のことは全て許せるので付き合った。付き合った当初は最高で、いつでも好きな顔を眺めたり、触ったり、キスできるというのは本当に幸せだった。そして4年が経ち(そのうち同棲2年)今は顔以外の彼の人間性も含めて本当に愛してる。私を安心させてくれるし、一緒に色々なことをポジティブに楽しめる関係だし、世界でただ一つの自分を無条件で肯定してくれる居場所ができたと感じる。家族のように大切で、これ以上のパートナーには出会えないと思う。 ここまでは完璧な関係に思えるのだが、一つ大きな問題がある。それは彼氏が太って肌が汚くなり、おまけに最近は禿げてきたのだ。 私は相手の顔さえよければそれだけでいいのだ

これまでもコンテナ関連の記事はそれなりに書いてきましたが、改めて最新事情に合わせて練り直したり見渡してみると、大きなところから小さなところまで選択肢が多すぎると感じました。 コンテナ系アーキテクチャを丸っと他所の構成で真似することって、おそらくほとんどなくて、参考にしつつ自分流に築き上げていくでしょうから、今回は築くにあたってどういう選択肢があるのかにフォーカスした変化系で攻めてみようと思った次第です:-) 目次 今年一発目の長いやつです。半分は学習教材用、半分は道楽なテイストです。 はじめに 基盤 インスタンス or コンテナ ECS or EKS on EC2 or FARGATE X86 or ARM64 ロードバランサー メンテナンス：ALB or ECS Service 共有 or １環境毎 アクセスログ：ALB or WEBサーバー ECS / EKS デプロイ：Blue/Gr

こんにちは、小俣です。 クリスマスも終わって一気に年末ムードですね。 ふとこれまでの振り返りブログを書いてみたくなったので、自社サービス(SaaS)の運営スタンス、ARR 2億円を突破するまでの過程で学んだことなどを簡単にまとめました。 年末年始のお時間ある時に読んでいただけると嬉しいです。 目次 ・selfree LLCとCallConnectについて ・CallConnectはハッカソンから始まった ・黒字化まで ・ARR1億、2億円を達成するまで ・失敗しながら学んだこと ・おわりに selfree LLCとCallConnectについて セルフリーは「愛される企業を増やす」を理念に、いわゆるスタートアップ的な成長志向ではなく、自分たちのペースで着実に成長することを志向している会社です。 経営のコントロール性の観点などから、これまで外部からの資金調達はしておらず、「ブートストラップ経

PublickeyのIT業界予想2024。ハイパースケーラーの優位性高まる、AzureはAWSに追いつくか？ ITエンジニアの給与レベル上昇 新年明けましておめでとうございます。今年、Pubickeyは15周年を迎えます。長きにわたってこの小さなメディアを続けられているのも読者の皆様のおかげです。今年もPublickeyをどうぞよろしくおねがいします。 さて、2024年最初の記事では今年のIT業界、特にPublickeyが主な守備範囲としているエンタープライズ系のIT業界について、期待を込めた予想をしてみたいと思います。 続くモノやサービスの値上げ、生成AIの爆発的普及など まずは予想の前提となる、世の中全般に関する現状認識について書いておこうと思います。 1年前を振り返ってみると、ロシアによるウクライナ侵攻や長引く新型コロナウイルスの感染拡大の影響などの複合的な要因で、石油や天然ガスを始

年明けの暇な時間を利用して読んでみました。 書籍のリンク 技術書としての感想 良かった点 悪かった点 注意点 総評 技術書としての感想 良かった点 とにかく文章が分かりやすい 色々な用語の使い方に違和感がない 言葉にすると簡単ですが、本当に分かりやすかったです． 具体例が豊富 図が豊富 コード例が豊富 実験例が豊富 まず、「〇〇 な場合に命令の処理が詰まって遅くなります」といった説明の後に、「では、具体的にこういったケースを考えてみましょう」という具体例を持ってくる展開が多く、とても親切だと感じました．また、このような具体例の説明のときにほぼ必ず図が用いられています．特に全体を通して頻繁に出てくる命令流の図は非常に分かりやすかったです．また、コード例とそれを用いた実験も豊富でした．具体的には、キャシュの章では実際にキャッシュミスを意図的に起こすコード・キャッシュヒットを意図的に起こすコード

「JAWS-UG東京リブート企画！ランチタイムLT会」での発表資料です https://jawsug.connpass.com/event/289824/

シングルスレッドやマルチプロセスなどの並行処理の話について、 すぐに忘れてしまいます。 どうしたらもっと知識が定着すると思いますか？ 色んなライブラリーでAPIサーバーを立ててパフォーマンスの差などを見てみたりするのですが、結局よくわかりませんでした。 フレームワークに頼って実装していると、そのフレームワークが内部でどの様な仕組みで並列または並行処理しているのかが理解できず、ただ使っているだけの状態になり得ます。 フレームワークの設計者からすると、プログラマがそれらを気にしなくても利用できるというのがプロジェクトのゴールでもあるので、それはそれで正しいのですが「並列処理」や「並行処理」を理解したいというモチベーションでは逆にそれが邪魔をしてしまうかもしれません。 並行処理や並列処理を学ぶのであれば、API サーバ等といった物ではなく、コード片で学び始めるのが良いと思います。 例えば Rub