ssmonline #43 での発表資料です。 (運用設計ラボ合同会社 波田野裕一)
運用改善、不都合な真実 / 20240722-ssmjp-kaizen
ssmonline #43 での発表資料です。 (運用設計ラボ合同会社 波田野裕一)
メール配信システムを SaaS から新規社内システムへ移行した - エムスリーテックブログ
この記事はエムスリーAdvent Calendar 2023の20日目の記事です。 エムスリーエンジニアリングG コンシューマチームの松原(@ma2ge)です。 今回はコンシューマチームで利用していたSaaSのメール配信システムを、新規に開発した社内システムに移行した経緯や設計時に意識したことなどについて紹介します。 最近使っているキーボードの様子 背景 今回移行する契機となったのはメールの配信数増加に伴うSaaSの利用料金増です。 特に定期的に送るメルマガ配信については、配信量も多く利用コストを押し上げる要因となっていました。 そのためメルマガ配信で大量に使用する部分についてのシステム移行検討が始まりました。 移行検討 SaaSから移行後のシステムについて試算すると、システムの開発や利用料といったコスト面では社内で構築したシステムの方が大幅にコストが下がることがわかりました。 しかしなが
設計ドキュメント腐る問題、Git管理で運用してみた結果 | フューチャー技術ブログ
はじめにTIG真野です。 秋のブログ週間2023 の3本目は、設計ドキュメントをGit管理して腐らせないようにがんばってみた話をします。 前段として6年前、「我々はいかにシステム開発におけるドキュメント腐る問題と戦えば良いのか」という記事を書いたのですが、その後の試行錯誤はどこにも残していないことに気づきました。普段のフューチャー技術ブログですとちょっと引け目を感じるテーマですが、秋の夜長を楽しむため読み物成分を多めに書くというテーマのこのブログリレーにピッタリな気がするため、この機会をお借りします。 ドキュメントも色々な種別があるかと思いますが、この記事では設計ドキュメントを指すことにします。設計ドキュメントは開発メンバーが参照するもので、ステークホルダーへの説明資料に引用して使うことはあれど、主目的は異なるという前提です。Design Docの場合もありますし、システム構成図、ERD、
AWSコスト削減とリソース管理 | 外道父の匠
クラウド使いなエンジニアの皆様、猛暑と円安の中いかがお過ごしですか。上層部からインフラコスト削減を突きつけられてはおりませんでしょうか。 今回はおそらく初めてコスト削減についてAWSを軸に書いていきますが、考え方はどこの環境でも似たりよったりなので何かしらの足しになればと思う次第であります。 目次 長いです。ひきかえしたほうがいいぞ！ コミュニティに捧げます AWSの売上 コスト削減とは 三大使命 コスト状況整理 Load Balancer 参考リンク 統合による削減 EC2 Autoscaling 参考リンク 情報整理 古いインスタンスタイプの変更 スケジュールの調整 スポットインスタンスの適用 軽量インスタンスの統合・サーバーレス化 アプリケーション処理の軽減 EC2 EBS EBSは高い 不要EBSを削除・スナップショット化 ボリュームタイプの変更 EC2 AMI NAT Gatew
秒間 10,000 リクエストを "簡単に"いなすゲームサーバーを Laravel で作る設計
1秒間に PHP が受信する HTTP リクエストが最大 10,000 回以上——— そんな世界が存在します。その一つが 「ソーシャルゲーム」 です。メンテナンスが明けた瞬間、イベントが始まった・終わる瞬間、様々なタイミングでゲームサーバーは瞬間的に高負荷になります。もちろん、サービスをリリースし PR をたくさん出し始めたその瞬間が、プロジェクトで最も高負荷となるでしょう。それらに耐えうるサーバー構成が求められていますが、「リリース直後にサーバーがダウンした」「限定イベントが始まったらすぐ緊急メンテナンスが始まった」という話はちょくちょく聞こえてきます。その 瞬間的な高負荷(いわゆる "スパイク") に耐えるには、事前準備を怠らないことが重要です。 ソーシャルゲームにおいては、他の Web アプリケーションに比べ 書き込みヘビーなワークロード であることが多いです。読み込みは比較的簡単に
コンテナ運用におけるログ基盤設計のベストプラクティス - Qiita
課題 数年前と比較すると、GKEやECSを始めとするコンテナ実行環境でのアプリケーション運用を行うサービスはかなり増えてきた印象があります。 コンテナを運用する上では、アプリケーションのイベントを追跡する上でログをどう扱うかが課題になります。今までのように古いログを定期的にローテートして別のストレージに転送するといった手法はクラウドネイティブなアーキテクチャには最適とは言えません。 アプリケーション開発の方法論として、Twelve Factor App ではログをイベントストリームとして扱うためのガイドラインが示されていますが、近年のWebアプリケーションではシステムを疎結合に連携するマイクロサービスという考え方が主流になりつつあります。 アプリケーションログはサービスごとにフォーマットを整形した上で、ログ収集サービスに配送。必要に応じてリアルタイム分析や異常データの通知、そしてデータの可
AWS システム構築 非機能要件ヒアリングシートを公開してみた | DevelopersIO
こんにちは。 ご機嫌いかがでしょうか。 "No human labor is no human error" が大好きなネクストモード株式会社の吉井 亮です。 日本国内においても多くのシステムがクラウド上で稼働していることと思います。 俊敏性、拡張性、従量課金、IaS、セキュリティなどクラウドのメリットを享受しやすい所謂 SoE で多くの実績があるように感じます。 ここ1~2年は、社内基幹システム・情報システム、SoR 系のシステムのクラウド移行が本格化してきたというのが肌感覚であります。 クラウドでのシステムインフラ構築は従来のようにゼロから非機能要件定義を行っていくものではなく、ベストプラクティスをまず実装して少しずつ微調整を行っていくものと考えています。とはいえ、システムごとの要件は予め明らかにしておくことがインフラ構築においても重要になります。 クラウド上では出来ること出来ないこと
暗号鍵管理ガイドライン | 情報セキュリティ | IPA 独立行政法人 情報処理推進機構
実際の暗号システムがセキュアに動作し続けるためには、暗号アルゴリズム自体がセキュアであるだけでは不十分で、データが保護される期間中、その暗号アルゴリズムが使用する暗号鍵もセキュアに管理されている必要があります。そのため、暗号鍵やデータのライフサイクルを踏まえた運用、安全な暗号鍵の保管、暗号鍵危殆化時の対策などを行う上で参考となるガイドラインを取りまとめています。 「暗号鍵管理システム設計指針（基本編）」の内容 「暗号鍵管理システム設計指針（基本編）」は、あらゆる分野・あらゆる領域の全ての暗号鍵管理システムを対象に、暗号鍵管理を安全に行うための構築・運用・役割・責任等に関する対応方針として考慮すべき事項を網羅的に提供し、設計時に考慮すべきトピックス及び設計書等に明示的に記載する要求事項を取りまとめたガイドラインとして作成されたものです。 具体的には、暗号鍵管理の必要性を認識してもらうために「
ネットワークエンジニアとして
ネットワークエンジニアとしての Network Studyでは、これからネットワーク エンジニアになりたいと考えている方や、CCIEレベルのネットワークエンジニア になりたいと考えている方に役立つよう基礎から上級レベルまでNW技術を解説。 Network Studyの内容は、国家資格であるネットワークスペシャリストの取得や CCNA/CCNP/CCIE取得に役立つ内容に仕上げているだけではなく仕事で役立つ ようにCisco、Juniper、F5の製品にフォーカスして実際の設定コマンドも解説。 今後もネットワークエンジニアの皆さんの役に立てるように、最新の幅広い技術 解説を行っていきます。内容に誤字や記載ミスがあればご指摘頂けると幸いです。 ネットワークエンジニアとは、その将来：ネットワークエンジニアがどのような仕事内容であるのかを紹介、ネットワークエンジニアの将来性について ネットワークエ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「SPAのタブ永遠に開きっぱなし問題」を更新ボタンを設置せず解決した - 橋本商会
要件定義に関わる人は３億回くらい読んでほしい−−−−−−−−−−「IPA 独立行政法人 情報処理推進機構 超上流から攻める IT 化の原理原則 17ヶ条」
shiodaifuku.io