安く早く開発するための個人開発アーキテクチャ
はじめに 最近趣味で個人開発をしながらアーキテクチャの検討を行なっていたのですが、自分なりにいい感じの結論に辿り着いたので今回はそのアーキテクチャの紹介しようと思います！ インフラ、バックエンド、フロントエンドの各セクションに自分が使用しているテンプレートのリポジトリのリンクを載せてあるので興味のある方は参考にしてください。 また今回紹介するアーキテクチャはあくまで一例なので、間違いや不備などがあればご指摘いただければ幸いです。 前提条件 個人開発で使用するアーキテクチャを考える上で、自分の中でいくつか前提条件があります。 ランニングコストを抑える いくつか前提条件がある中で、個人的に一番重要な要素になります。 バズるサービスを作りたいという気持ちはありますが、そのためにいくらでもコストをかけられるかと言われるとそうではありません。むしろ個人開発となると、抑えられるコストはできる限り抑えた
Service Meshがっつり入門/Get-Started-Service-Mesh
OCHaCafe Season6 #1の資料です．
DBのリストアテストを全自動化した話 - Pepabo Tech Portal
ホスティング事業部の業務信頼性向上チームでエンジニアをしているはらちゃんです。 先日STREET FIGHTER 6のオープンベータに参加し、友人にボコボコに負けました。 製品版買っていい勝負ができるように特訓を重ねたいと思います。 今回、ホスティング事業部のサービスであるロリポップ、ムームードメイン、ヘテムル、おさいぽのDBリストアテストを自動化したので紹介します。 まず業務信頼性向上チームとは？ リストアテストを継続的にやっている理由 なぜ自動化したのか 全体像 具体的な実装 実装時に困ったこと dumpのサイズが大きすぎて通常のrunnerではリストアテストができない場合 scpをするアカウントにdumpファイルを操作する権限がない場合 dumpファイルのファイル名が微妙に違ってうまく指定できない場合 終わりに まず業務信頼性向上チームとは？ 最初に、自分の所属している業務信頼性向上
7年続いたサービスをEC2構成からECS構成へ乗り換えた話 - KAYAC engineers' blog
この記事は Tech KAYAC Advent Calendar 2021 の20日目の記事です。 こんにちは、バックエンドエンジニアの @commojun です。今年のTech KAYAC Advent Calendarは3度めの参戦です！よろしくお願いいたします！ 本日の記事は、昨年の記事の続きで、Amazon EC2のプロダクトをAmazon ECS構成へと乗り換えた話になります！ techblog.kayac.com 目次 目次 背景 Amazon Linuxのサポート終了 ついでにPerlのバージョンもあげた 苦労したポイント 1，デプロイ方法がめっちゃ変わる デプロイのために都度コンテナイメージを焼く 2階建て作戦 2，batchサーバどうするの問題 sqsjfr + SQS + sqsjkr 作戦 3，泥臭い戦い ecspressoの存在 非エンジニアにもわかってもらおう 「
くらめその情シス：クラスメソッドの基幹ネットワーク構成を紹介します。 | DevelopersIO
はじめに どうも、情シスの徳道＠上越オフィスです。今回はネットワークネタです。 唐突ですが、会社を代表するグローバルIPアドレスって多くの場合は本社の固定グローバルIPアドレス（プロバイダに依存）ではないでしょうか。 ゼロトラストが叫ばれて久しいですが、弊社のようにお客さまの環境を保守するサービスを行っている場合、やはり境界防御として接続元のグローバルIPアドレスを指定して許可されることが多いです。 地方オフィスが増えてくると特定の環境への接続許可をしてもらうIPアドレスの登録も増えてきます。VPN接続で本社など特定拠点経由での接続を行っていたとしても、プロバイダに依存することになったり冗長化が大変だったりしますね。 弊社では数年前からAWSのElastic IP経由で変化しない&冗長化されたグローバルIPアドレスからAWSに接続する社内ネットワークを構築してきました。 今回はクラスメソッ
インフラエンジニアというキャリアの話 / be-infra-engineer!
@フィヨルドミートアップ 2020/09/24
システム構成図をテキストで
Gigazineさんでdrawthe.netを取り上げていたので紹介です。使い方はGigazineさんのほうが丁寧なので、気になる方はチェックしてみてください。（2020年12月1日、追記） drawthe.netとは cidrblock/drawthe.netは複雑なネットワーク図も「テキストで書いてブラウザ上でSVGレンダリングできるようにしよう」というコンセプトのもと開発されたツールです。下図のように複雑な構成図も精度高く描くことができます。 拡大してみると情報量が多いこと、またいかに整っているかがわかると思います。 デモサイトも用意されているので、サクッと試したい場合はコチラが便利です。コードはGitHubで公開されています。更新が2017年末で止まってしまっているのが玉に瑕ですが、十分な性能を発揮してくれます。 drawthe.netを使いたい理由 美しい構成図といえばInter
小規模（5〜20人）オフィスのネットワーク構築例
背景 株式会社マインディアCTOの@matsubokkuriです。 事業規模の拡大に伴いオフィスの移転がありました。それに伴い社内ネットワークインフラの構築しました。オンサイトで働く人は約10名。エンジニアは私1名なのでインフラ整備を自分でやるか外注するかという選択でしたが、外注するためにはRFP作るのが面倒だし費用がかかるのでDIYしました。 中小企業のネットワーク構築の記事は5年前の@wadapさんの記事が詳しいです。その記事以降、まとまった社内LAN構築の良い感じのノウハウ記事を見つけられませんでした。その5年の差分を埋めるためにも記録を書いておきます。 要求定義 ゲスト用ネットワークの分離（インターネット回線、LAN回線） 将来のシステム監査で指摘されるであろうことなので。 トラフィックのQoS制御のため。 インターネット上のホストにおいてグローバルIPアドレスによるアクセス制限が
データ収集の基本と「JapanTaxi」アプリにおける実践例
データ収集の基本として、データソース毎に典型的なデータ収集方法を整理して説明しています。またJapanTaxiアプリにおいてどのように実践しているかを説明しています。Read less
仮想サーバ17万台、物理サーバ9万台 「ヤフオク!」「Yahoo! JAPAN」を支えるヤフーのITインフラ運用術
仮想サーバ17万台、物理サーバ9万台 「ヤフオク!」「Yahoo! JAPAN」を支えるヤフーのITインフラ運用術（1/2 ページ） 国内最大級のポータルサイト「Yahoo! JAPAN」をはじめ、ECサイト「Yahoo!ショッピング」やオークションサイト「ヤフオク!」など、コンシューマー向けWebサービスを数多く運営するヤフー。同社はこれらのサービスを裏で支えるシステム基盤として、大規模なプライベートクラウド環境を自社で構築・運用している。 ヤフーの奥村司さん（クラウドプラットフォーム本部 プライベートクラウドチーム リーダー）が、クラウドインフラの運用管理者向けイベント「Cloud Operator Days Tokyo 2020」で明かしたところによると、その規模は、仮想サーバが約17万台、物理サーバが約9万台。物理サーバのうち2万台がIaaSの仮想化ハイパーバイザーとして使用されて
理解して拡げる分散システムの基礎知識
20200725の #JTF2020 セッションスライド。 （資料内で説明した資料へのリンク） ・昨年のJTF発表資料 https://speakerdeck.com/tzkoba/cloud-nativekai-fa-zhe-falsetamefalsedatabase-with-kubernetes ・「2020年のNewSQL」 https://qiita.com/tzkoba/items/5316c6eac66510233115 ・「NewSQLのコンポーネント詳解」 https://qiita.com/tzkoba/items/3e875e5a6ccd99af332f ・Saga https://www.infoq.com/jp/news/2018/03/data-consistency-microservices/ ・「マイクロサービスとは分散システムである」 https://
SHOWROOM株式会社の映像配信遅延が業界最速レベルに縮まったので嬉しいという話 - izm_11's blog
概要 現在僕はSHOWROOM株式会社というところでxRのクライアントエンジニアをしています。 が、SHOWROOM株式会社はライブ配信サービスを行っています。 今回の記事は、このライブ配信サービスの方でかなり面白い取り組みが行われて、世に出たので面白さをみんなに布教したいと思って書きます。 prtimes.jp ライブ配信サービスの話 SHOWROOMは国内ライブ映像の配信サービスとしては古株で、確か6年くらいの歴史があります。 その後pixivさん(pixiv Sketch)やCyberZさん(OPENREC.tv )や、LINEさん(LINE LIVE)など、色々な会社さんがライブ配信サービスを生み出して、国内の市場は活気づいています。 配信者と視聴者間でコメントやギフティングでリアルタイムコミュニケーションを取る感じの仕組みです。 SHOWROOMの技術的負債 先ほど説明した通りに
インフラエンジニアのスキルパターンを作ってみた話
Visual Studio Users Community Japan #1 で発表した資料になります。 https://vsuc.connpass.com/event/143114/
AWS導入前に知っておきたかった「AWSアカウント設計」 - Qiita
1.はじめに みなさんAWSのアカウント設計はどのようにしていますか？ AWSを使ってシステムをセキュアに開発・運用していくためには、 AWSアカウント(*)の設計が重要になりますよね。 AWSアカウント1つのみで運用されてる方は、誤操作や、 誰にどの権限を与えるかのポリシー設計等で困る方もいらっしゃるのではないでしょうか。 (私もその一人です。) 本内容は、『Amazon Web Services 業務システム設計・移行ガイド』にも載っているので、 悩んでる場合は、購入をおすすめします！（こちらの書籍と実体験を元に書いてます。） 今回はAWSアカウント設計について、パターン別にメリット・デメリットを書いていこうと思います！ (*)AWSアカウントとは、AWSを使用するためのマスターアカウントのことを指しています。 ※IAMユーザーとは別物です！ 2.AWSアカウント設計パターン紹介 本章
「あけおめLINE」の負荷に耐えるインフラを作った話。LINEのインフラ設計を中の人に聞いた｜ハイクラス転職・求人情報サイト AMBI（アンビ）
「あけおめLINE」の負荷に耐えるインフラを作った話。LINEのインフラ設計を中の人に聞いた 国内外で展開する膨大なメッセージを処理する、LINEアプリのインフラってどうなっているの？ こんな素朴な質問をサーバー、ネットワークなど、中の人に聞いてみました。 2011年6月のリリース以来、右肩上がりの成長を続けるコミュニケーションアプリ「LINE」。主要4カ国（日本・タイ・台湾・インドネシア）の月間アクティブユーザー数は1億6,400万人を超えており、多くの人々にとって必要不可欠な社会的インフラにも等しいアプリになっています。 そして、多数のユーザーを抱えるアプリでは、膨大な量のトラフィックやデータを前提としてインフラアーキテクチャを設計する必要があり、インフラエンジニアの技術力がアプリの使い勝手に大きな影響を与えます。 本稿では、LINE株式会社のサーバーサイドエンジニア 中村俊介さん、サ
真っ当な技術を使ったふつうのWebサービス開発––Webメディアのリニューアルにおいて考えたこと
真っ当な技術を使ったふつうのWebサービス開発 Webメディアのリニューアルにおいて考えたこと 真っ当な技術を使ったふつうのWebサービス開発 2018年12月6日、株式会社リンクアンドモチベーションのイベントスペースにて、エンジニア向けの勉強会に特化した書き起こしメディア「ログミーTech」が主催するイベント「ログミーTech Live #2」が開催されました。第2回となる今回のテーマは「レガシーシステムのリニューアル」。長期間運用され、設計が古くなってしまった「レガシーシステム」のリニューアルを行った3社が一堂に会し、システムリニューアルにおける知見と新システムへの移行について語ります。プレゼンテーション「真っ当な技術を使ったふつうのWebサービス開発」に登場したのは、ログミー株式会社エンジニアの野崎翔太氏。Webメディア『ログミー』のリニューアルをたった1人で担当し、設計から実装まで
絶対失敗できないライブ放送を支えるNewsPicks動画基盤 - Qiita
あいさつ こんにちは。NewsPicksエンジニアの桐畑と申します。NewsPicksAdventCalendar2018の8日目を書かせていただきます。今日はNewsPicksの動画基盤についてお伝えできればと思います。 NewsPicksの動画 NewsPicksでは、2017年からテキストコンテンツではなく、動画コンテンツを開始しています。立ち上げ当初は経済メディア×動画は難しいと言われていたのですが、トライアンドエラーを繰り返し、今ではユーザー獲得ドライバーのコンテンツへと成長を遂げています。 人気のコンテンツとしては、WEEKLY OCHIAIやメイクマネーなどがあります。WEEKLY OCHIAIは、リアルタイムのライブ配信で毎回、出演者の皆さん・制作陣の皆さん・エンジニアが全力を尽くして番組を放送しています！ 概要 NewsPicksの動画配信では、クラウドサービス(AWS
Google Colaboratory で機械学習させる際のインフラ整備 - Qiita
Google Colaboratory で機械学習を行う際に、3点詰まったので解決策をまとめておきます。 問題と(解決策) Colabが90分ごとに落ちる（Auto Refresh） 学習データの読み込み、容量問題（Google Driveをマウント） 自動削除された学習済みモデルがゴミ箱にたまり続ける、容量問題（Google Apps Script） Colabが90分ごとに落ちないようにする コラボは一回12時間使用可能ですが、操作しないと90分で落ちてしまいます。その時はこの記事を参考にGoogle Chrome拡張機能のAuto Refreshを入れましょう。この記事に追加する形で一点だけ注意があり、ノートブックの出力を非公開にしておきましょう。そうしないと2回目以降の再読み込みでも手動で再読み込みボタンをクリックする必要があります。Colabのタブから編集→ノートブックの設定→こ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
リアルタイムログ分析基盤のAWS-_GCP移行話
AWS vs GCP 今から作る ならどっちがいいの!?
