タグ

infrastructureに関するymm1xのブックマーク (42)

  • Zenlogicホスティングが断続的にご利用しづらい状況について|プレスリリース|ニュース|Zenlogicのファーストサーバ株式会社

    TOP サービス IDCFクラウド コンピュート コンテナ RDB CacheDB クラウドストレージ バックアップ DNS GSLB(広域負荷分散) インフィニットLB CDN イメージオプティマイザー 連携サービス プライベートクラウド NSXオプション ベアメタルサーバー パートナーサービス Fastly CDN Fastly 次世代 WAF SiteGuard Server Edition Google Cloud 構成例 事例 料金シミュレーション 今後の機能強化予定 English

    Zenlogicホスティングが断続的にご利用しづらい状況について|プレスリリース|ニュース|Zenlogicのファーストサーバ株式会社
  • サーバの適切な名前の付け方 | POSTD

    現在、 MNX ではクラウドホスティングサービスの新しいデータセンタを立ち上げているところで、とてもバタバタしています。クラウドホスティングサービスは、今の私たちの主な業務ですが、この会社が始まった当初は、Linux管理のコンサルティングサービスを中心としていました。そのサービスを通じて、たくさんの顧客環境を目の当たりにしましたし、それと同じ数だけの、顧客ごとに異なるデバイス名の指定方法も見てきました。そしてもちろん、その全ての指定方法をいいなと思ったわけではありません。名前の付け方は、コンピュータ草創期からの問題ですよね。おのおのがホスト名の指定方法について一家言持っていました。でも、それらの方法は最初のうちはうまくいっても、時を経てシステムインフラが拡大し、状況に応じて変更を余儀なくされるようになると、すぐに扱いにくくなってしまうものがほとんどでした。 そこで今回は、先述した私たちのデ

    サーバの適切な名前の付け方 | POSTD
  • PayPayの1秒あたり1000決済への道のり

    パフォーマンス・チューニングに関するブログの第1回目です PayPayは、日でもっともよく知られているQR決済サービスとなりました。2018年10月5日のローンチ後、2018年12月より実施した100億円あげちゃうキャンペーンは、その後のプロダクトの急成長に合わせたシステムのスケール拡張という長い道のりのスタート地点でもありました。 ここ数ヶ月の新規ユーザーの増え方[1]を見るにつけても、PayPayが驚異的な成長を続けていることは間違いありません。スタートアップ企業はまるで竹のように成長するとはこのことではないでしょうか。(竹は24時間で最大約90cmも伸びるそうです) PayPayの成長速度は? ユーザー数の伸び 2018年10月に初めてユーザーが増え、キャンペーンや日々メディアで報道されることによるユーザー数の増加もあり、1年後には1500万人を突破しました。2020年5月現在、サ

    PayPayの1秒あたり1000決済への道のり
  • Amazon ECS クラスターの Auto Scaling を深く探る | Amazon Web Services

    Amazon Web Services ブログ Amazon ECS クラスターの Auto Scaling を深く探る 概要 つい最近まで、ECS クラスター内での EC2 インスタンスの数を、タスクとサービスに合わせてスケーリングさせようとすると、難しい問題の発生することがありました。  ECS クラスターは必ずしも必要なときにスケールアウトするわけではなく、スケールインは注意深く扱わないと可用性に影響を及ぼします。ときには、顧客はこの課題に対応するため、Lambda 関数などのカスタムの手法、カスタムのメトリクス、そして重量挙げにも例えられるような他の手段に訴えましたが、あらゆる状況でうまくいく単一のアプローチはありませんでした。もちろん、タスクを EC2 インスタンスの代わりに Fargate で実行すれば、クラスターのスケーリングの必要性は全くなくなりのですが、すべての顧客がすべ

    Amazon ECS クラスターの Auto Scaling を深く探る | Amazon Web Services
  • Kubernetesの自前運用はやっぱりツライらしい - orangeitems’s diary

    Kubernetesの自前運用は難しい これから嫌でもコンテナと戦わなければいかないインフラエンジニアには何度でも読み返してほしい記事です。 www.atmarkit.co.jp はてなMackerelチームはKubernetesクラスタを自前で構築して運用していたが、撤退を選択したという。なぜ、Kubernetesの運用を諦めて撤退を選んだのか。はてなMackerelチームでSREを務める今井隼人氏が語った。 考察 この話、20年前のLinux草創期を思い出すんです。 雑誌の付録にLinuxがCD-ROMで付いてたんです。最近のスマートなCentOSとかじゃなくてですね、何Linuxだか忘れたのですがインストールも含めて3日間ぐらいかけて取り組んだんですが結局失敗した記憶があります。 これからKubernetesなりコンテナがやってくるのはここ最近に書いた通りで、早くそっちの世界に行

    Kubernetesの自前運用はやっぱりツライらしい - orangeitems’s diary
  • Kubernetesでステートフルなゲームサーバを動かした思い出

    とあるスマートフォン向けMMORPGプロジェクトで、アプリケーションサーバをほぼすべてGKE(Google Kubernetes Engine)に乗っけて動かしていました。 このゲームは、モバイル向けながら、複数プレイヤ間でそこそこリアルタイム性の高い同時プレイができるものでした。同じフィールドを誰かが歩けば、自分が見ている画面でもほぼ同時にそいつが歩いて横切っていく、同じ敵と皆で一緒に戦えば、誰かが繰り出した攻撃が参加者全員の画面に即同期される、もちろんチャットもできる、そんな具合です。今ではさほど珍しくないのかもしれませんが、PCのオンラインゲームのような機能を搭載した、リアルタイム性の高いモバイルゲームでした。 さて、こうなってくると、オーソドックスなWebサーバのような、HTTP/1でリクエスト/リプライを捌く、というサーバだけでは要件を満たすことができません。 複数プレイヤ間で

    Kubernetesでステートフルなゲームサーバを動かした思い出
    ymm1x
    ymm1x 2019/04/05
  • 個人からプロまで使えるゲームサーバー - Game Server Services(GS2)

    Hassle-free Gaming Backend Services: Focus on Gamers not Servers ゲーム開発に必要な30を超えるサーバー機能を提供 新しく作らない。すぐ使える。運用しなくていい。 初期費用・固定費用なしの従量課金。開発・運用コストを削減できる SaaS 型汎用ゲームサーバ 今すぐ無料登録 What can GS2 do? 《対戦・協力プレイ》にフォーカスしている他社とは大きく異なります 《長期運営》のための汎用ゲームサーバーです

    個人からプロまで使えるゲームサーバー - Game Server Services(GS2)
  • 株式会社コロプラの導入事例:Google Cloud Platform への移行によって、難度の高いモバイルゲーム サービス運用を徹底的に効率化・低コスト化 | Google Cloud 公式ブログ

    株式会社コロプラの導入事例:Google Cloud Platform への移行によって、難度の高いモバイルゲーム サービス運用を徹底的に効率化・低コスト化 2018 年 10 月で 10 周年を迎えた、国内モバイルゲーム サービスの雄、コロプラ。現在、137 タイトルほどのゲームを提供しているという同社が、昨年夏からサービスのバックエンドを Google Cloud PlatformGCP)に移行しています。そこにはどのような狙いがあるのでしょうか。Kubernetes Engine(GKE)や、Cloud Spanner などの活用法についてもお伺いしてきました。 写真左から 取締役 CCO クリエイティブ部長 菅井 健太氏クリエイティブ部 第1エンジニアリング部 第4グループ  粟田 大樹氏業務推進部 インフラグループ 第2チーム リーダー 邵 正氏業務推進部 インフラグループ

    株式会社コロプラの導入事例:Google Cloud Platform への移行によって、難度の高いモバイルゲーム サービス運用を徹底的に効率化・低コスト化 | Google Cloud 公式ブログ
  • https://blog.animereview.jp/zero-trust-architecture/

    シンジです。社内インフラを構築するとき、何を指標として設計しているか、何のために作るのか、誰が嬉しいのかを考えずに淡々と予算を投入している企業の多いこと多いこと。これから会社を作るならまだしも、既存企業は長年の蓄積があるわけです。物理機器や、買収合併の弊害、シャドーITに働き方改革推進の圧力。これらに個別的に対処することこそが無駄かつ自己満足なので、自社のインフラはどうなるべきだったのかを考えたい物です。 ITは企業にとってコアである 企業や組織運営において、ITを使うことで便利になったり、効率が良くなったりする程度の時代はとっくに終わっています。企業や組織からIT全てをとっぱらってしまうと、企業や組織が消え去る可能性が非常に高い、というか確実に死ぬであろう状態にまでITに依存しています。つまり現代においてはITはコアなのです。 情報システム部門はその重要性を理解していない 企業においての

    https://blog.animereview.jp/zero-trust-architecture/
  • ミクシィグループのサービスと利用技術(技術スタック)についてまとめてみた|ミクシル

    コメント 2017年からスタートしているスマートヘルス事業部は、コミュニケーションと運動を通じて健康寿命を延伸することをビジョンに掲げています。具体的には、予防理学療法に基づいて身体の歪みやバランスの計測・評価を行い、身体の状態に合わせた運動プログラムを提供していきます。 エンジニアの平均年齢は24.5歳と若いメンバーで構成された組織で、それぞれが専門技術を持ち、様々な技術を駆使してサービスを実現しています。 今後は、サービスを提供する実店舗のオープンや、ヘルスケアアプリの提供、サービス利用者のPHR※を蓄積したデータベースの構築など、多角的なアプローチで日の健康寿命延伸に取り組む予定です。 ※Personal Health Record スマートヘルス事業部 開発グループ マネージャー 橋口 Find Job!、COSMiKA 事業部の取り組み 「Find Job!」「COSMiKA」

    ミクシィグループのサービスと利用技術(技術スタック)についてまとめてみた|ミクシル
  • Behind the scenes with the Dragon Ball Legends GCP backend

    Product updates, customer stories, and tips and tricks on Google Cloud Platform

    Behind the scenes with the Dragon Ball Legends GCP backend
  • mineo、「通信の最適化」実施前に説明せず謝罪

    ケイ・オプティコムが提供するMVNOサービス「mineo」で、ユーザーが送受信するデータを圧縮するなどしてパケットの総量を減らし混雑を緩和する「通信の最適化」が、事前に説明なく行われているとネット上で指摘が相次いでいる。同社は5月7日、「実施前に説明できていなかったこと、実施後も正式な見解をタイムリーに公表できなかったことを深くおわびします」と謝罪した。4月10日から実施していたという。 トラフィックが一定時間帯に集中すると通信速度が遅くなる恐れがあるため、通信回線を増強する一方、通信の最適化を実施したという。同社は、約款上に「契約者に事前に通知することなく通信利用の制限を行うことがあります」と記載していたが、「情報公開を積極的にしていく企業姿勢として、契約者の方々へ事前説明しておくべき事項だった」と陳謝している。実施内容の詳細は、あらためて報告するとしている。 ネット上では4月末から、同

    mineo、「通信の最適化」実施前に説明せず謝罪
  • 実例に学ぶ動画配信サービスの負荷試験〜テストケース作成からツール選定、性能劣化への対応まで

    実例に学ぶ動画配信サービスの負荷試験~テストケース作成からツール選定、性能劣化への対応まで ライブ動画ストリーミングプラットフォーム「SHOWROOM」で実施した負荷試験の内容とはどのようなものだったのでしょうか。DeNAのインフラ基盤を支えるエンジニア漢 祐介さんに、貴重なノウハウを徹底解説してもらいました! サービスが業務に耐えうる処理性能を持っているかを検証するため、システムに対して擬似的に大量アクセスを発生させて反応を測定する「負荷試験」。サーバーの限界性能を見極め、安定稼働させるための指標や仕組みを作るために、なくてはならないものです。 では、多くの人が知るサービスは、どのような負荷試験を経てリリースされたのでしょうか。すでに運用段階にあるサービスの背後にある負荷試験のノウハウは、これから何らかのサービスをリリースしようとしているエンジニアにとって有用な情報です。 そこで今回は、

    実例に学ぶ動画配信サービスの負荷試験〜テストケース作成からツール選定、性能劣化への対応まで
  • 今年流行りそうな「インフラエンジニア」向けトレンドのまとめ その1 (Blue-Green DeploymentとImmutable Infrastructure編)

    あけましておめでとうございます。バズワード評論家 横田でございます。(恐らく)皆様1月6日から出社ですね。お仕事がんばりましょう。 というわけで今年のインフラ業界のバズワードトレンドをまとめてみました。年始の仕事前にどうぞ 《Blue-Green DeploymentとImmutable Infrastructure》 今年のインフラ業界の一番のトレンドは「Blue-Green Deployment」と「Immutable Infrastructure」となる気がしています。今までは、サーバの設定を変更する時は、運用中のサーバを変更していましたが、「Blue-Green Deployment」と「Immutable Infrastructure」の考え方は、運用中のサーバの変更するのではなく、新しくサーバ群を用意し、番環境をそちらに切り替えるという手法を取っております。 手法自体は「Bl

    今年流行りそうな「インフラエンジニア」向けトレンドのまとめ その1 (Blue-Green DeploymentとImmutable Infrastructure編)
  • 目指せ!落ちない高可用性サーバ、ハードウェアの選び方 - Qiita

    10年以上金融機関で働いているインフラエンジニアの落ちないサーバにするための考察です。 ハードウェアの専門家ではないので、正確ではないかもしれません。 今までの経験からの個人的考え方になります。 私たちオンプレ重視のインフラエンジニアは、 クラウドサービスではできない高可用性サーバを導入したり、 複数台構成で1台故障しても問題ない構成のサーバはコスト重視するなど、 システムに最適なサーバを導入しようとしています。 高可用性サーバを追求する目的 ■アプリに影響を与えないように Active/Standby構成にしていて、インフラ的にはダウンタイムが数秒だとしても、 アプリによっては復旧に時間がかかったり、問題ないことの確認にも時間がかかってしまいます。 また、正しくサーバが落ちればアプリが問題ないとしても、 サーバが中途半端な状態のままになってしまい、なんだかおかしいということもあります。

    目指せ!落ちない高可用性サーバ、ハードウェアの選び方 - Qiita
  • hatebu.me

    We’re getting things ready Loading your experience… This won’t take long.

    hatebu.me
  • 大量アクセスを捌けるシンプルなインフラ構成 - Qiita

    ◎はじめに ・今更ながら大量アクセスを捌けるシンプルなインフラ構成って、なんじゃらほい。 というわけで考えてみました。 01. 前提 ・モデルは定期的に大量流入があるポータルサイト ・第一にアクセスを捌けること、第二に運用保守のことも(少し)考慮 02. 構成図 ・それで考えてみた構成がコチラ(※1) → 利用ツールはCacoo。直感で書くことが出来便利、いつもお世話になっております。 (※1) 社内にある事例を参考にしておりますmm また、先輩に相談しながら作成しました。多謝! → けれど、この構成に矛盾や不備があれば私の責任ですmm 03. 説明 ・上記構成図の簡単な補足になります。 03-1. CloudFrontってそんなに便利だったんですね。。 ・画像や動画などコンテンツの配信はキャッシュサーバでもあるCloudFrontを使うのが定石。 ただITリテラシーの低い私は当初、CFへ

    大量アクセスを捌けるシンプルなインフラ構成 - Qiita
  • RASIS - Wikipedia

    RASIS(読み:レイシスもしくはラシス[1][2])はコンピュータシステムに関する以下の代表的な指標の頭文字を並べたもの[1][2]: Reliability(信頼性) Availability(可用性) Serviceability(保守性) Integrity(完全性) Security(機密性) 特に最初の3つをRASという。RASやRASISは 機器、システムやコンピュータなどの総合的な評価の指標である[3][4][5][6]。 信頼性(Reliability)の代表的な評価指標としてシステムが安定稼働し続ける平均時間である平均故障間隔(Mean Time Between Failures、MTBF)があげられ、保守性(Serviceability)[7]の指標としてはシステムを修復するのにかかる平均時間である平均修理時間(Mean Time To Repair、MTTR)があげ

  • 月額2650円でDBアクセス込み秒間214リクエスト捌くWebサーバ構築事例 - Qiita

    Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

    月額2650円でDBアクセス込み秒間214リクエスト捌くWebサーバ構築事例 - Qiita
  • AWSとGCPでマルチクラウドインフラを構築した話とそのポイント | PLAID engineer blog

    ごきげんよう。プレイドの@tik-sonと申します。 みなさんはクラウドプラットフォームを利用していますか? 弊社のKARTEは 秒間3000イベントをリアルタイムで解析累計解析ユーザがリリースから2年で12.5億 https://karte.io/infographic/2017.htmlという規模のサービスになっています。 そこで動いているインフラもそれなりに大規模になっており、インフラをいかに改善していくかが事業進捗に大きく関わってきます。 そのインフラを改善する試みとして半年ぐらい前から、AWSGCPの2つのクラウドプラットフォームを組み合わせ、マルチクラウドインフラとして利用しています。 PLAID Enginner Blogでは複数回に渡ってマルチクラウドインフラを作る上で試行錯誤したポイントなどを紹介していこうと思います。 今回は初回ということで概要部分について記載し、次回

    AWSとGCPでマルチクラウドインフラを構築した話とそのポイント | PLAID engineer blog