この記事で書きたいことは、大筋以下のような内容です。 ・「勉強出来ない教育ママはとにかく塾に通わせたがる」的な話を読みました ・塾で全てが解決するわけではないのはまあその通りなのですが、マウントと煽り主体で「じゃあどうすればいいねん」という話を置いていき過ぎだなとも感じました ・塾が有効に動作しない時、その原因になるのは多くの場合「タスク管理不足」です ・人類はマルチタスクが苦手でして、その為タスク管理やタスク整理の練習を積まないといけません ・子どもに「勉強する気を起こさせる」ことは大抵の場合極めて困難ですが、勉強をするインフラを整え、タスク管理の技術習得を手伝ってあげることは出来ます ・どうすればいいの？→大きく三つあります。「広い机を用意して」「タスク可視化とタスク整理用のインフラを作って」「当初はなるべく子どもと一緒にタスク整理をしてあげましょう」 ・ただ、その上で「三歩進んで二歩
みなさん、AWS使ってますか！（挨拶 AWSに限らず、ある程度の規模の何かしらの本番システムを組もうというときに、こういう言葉を聞いたことはないでしょうか。 「負荷分散装置の下に並べる分散先 (サーバ) は３台以上がよい」 「AWS であれば３アベイラビリティゾーン (AZ) にまたがるとよい」 負荷分散装置（ロードバランサー）は負荷を分散するのがお仕事です。分散するだけなら 2 台でもよさそうですよね？ AWS の３ AZ に至っては、そもそも AZ 単位の障害なんてそうそうないし、あったとしてももう片方の AZ が生きていればなんとかなりそうに思えます。 これがどういうことか、少し考えてみました。 おさらい：負荷分散装置と可用性の関係について まずはおさらいです。 負荷分散装置（ロードバランサー）は単純化していえば、その名前の通りひとつの名前（FQDN）へのアクセスを複数のサーバに分散
![[初級編] なぜ「AWS で負荷分散は３AZ にまたがるのがベストプラクティス」と言われるのか 可用性の面から考えてみた | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/876809e40a16193d45c580a01a3f67fc9a50a044/height=288;version=1;width=512/https%3A%2F%2Fsiteproxy.ruqli.workers.dev%3A443%2Fhttps%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2019%2F05%2Felastic-load-balancing.png)
Linodeのメリットが得られやすいユースケースとは？佐藤裕行氏（以下、佐藤）：後半は、Linodeのユースケースについて、少し岡本さんと話を進めていきたいと思うんですけども。今回はアプリケーションの負荷試験にフォーカスして、デモなども見せていきます。 その前に、負荷試験以外のサービスでいうと、こういうのに向いているとか、こういうのに向いてそうなところって、なにか感覚として持ってたりしますか？ 岡本英輝氏（以下、岡本）：前半に続いて、ちょっと転送量コストの話ばっかりになってしまうんですけど、やはりアウトバウンド転送量を大きく消費するようなアプリケーションに非常に向いてると思っていて。映像の配信であったり、音楽の配信であったり、そういったものにはすごく向いてるんじゃないかなと思います。 もしくは音声通話やビデオ会議、そういったデータ通信量が多く発生しやすいものは、他社との比較ですごくコストメ
概要 皆さんAWSのインフラ管理どうしてますか？ なるべくならインフラ管理は自動化。手順書も作らず、資源作成時誰でもどの環境に対し同じものを作成したいですよね。 そんな時、Infrastructure as Code（IaC)を採用し、インフラ管理をコード化するのは当たり前になってきているんじゃないでしょうか。 AWSにおけるIaCだと例えば、Cloudformationとか、AWS CDKとかTerraform等、様々です。 ただ今回は、そんなIaCの紹介・・・ではなく、全く新しい概念のInfrastructure as SQL (IaSQL) なるものについて、ご紹介したいと思います。 Infrastructure as SQL (IaSQL) Infrastructure as SQL (IaSQL)とは何か。 => 一言で表すなら、インフラ構成をPostgreSQLで管理するための
技術部 SRE グループの鈴木 (id:eagletmt) です。 クックパッドでは Amazon ECS をオーケストレータとして Docker を利用しています。Docker 自体は2014年末から本番環境にも導入を始めていましたが当時はまだ ECS が GA になっておらず、別のしくみを作って運用していました。2015年4月に GA となった ECS の検討と準備を始め、2016年より本格導入へと至りました。クックパッドでは当初から Hako というツールを用いて ECS を利用しており、Hako の最初のコミットは2015年9月でした。 https://github.com/eagletmt/hako/commit/7f95497505ef78491f3f68e9d648204c7c9bb5e2 当時は ECS に機能が足りずに自前で工夫していた部分も多かったのですが、ECS やそ
まえがき IT業界で10年弱努めて見て、現在は教育部門にいることもあり”新人教育に向いている教材は有りませんか？”という質問を頂くことがあります。 昨今ITに関する様々な知識は情報が溢れていて、少し検索エンジンで調べれば大量のリソースにすぐアクセスができます。 一方で、本当に価値があるものも大量の情報の中に埋もれてしまいがちです。 本記事が目指すポイントとしては、”これからIT業界でインフラエンジニアとして頑張るぞ”という方向けが、短時間で良質なリソースにアクセス出来るようにすることです。(私自身のおすすめ色が強いです) なお、ここで想定する”インフラ”というのは次の要素を想定しています。 サーバ オペレーティング システム ストレージ ネットワーク 仮想化 パブリッククラウド ですから、次のようなカテゴリについては全く触れていない、あるいは触れていてもかなり部分的だと言う点をご理解下さい
こんにちわ。rwle1212です。 本記事は JAWS Days 2020 で話す予定でしたが、昨今の事情によりオンライン開催となったため、登壇予定の内容を記事にしたものになります。 登壇していれば諸般の事情により左手首を骨折したネタが使えたのですが、ブログでは伝わらないので非常に残念な思いをしております。という話はどうでも良いので本題に入ります。 50分の登壇内容なので少々長くなりますが、お付き合いください。 JAWS Days 2019で登壇した内容の振り返り昨年の JAWS Days 2019 で「Infrastructure as Codeに疲れたので、僕たちが本来やりたかったことを整理する」という内容で登壇しました。 まずは上のリンクに添付されているスライドを5分位で読めると思うので一読頂いて、下の文に進んで頂ければと思います。 そもそもInfrastructure as Cod
Kubernetesによる インフラ共通基盤 - JapanTaxi Kubernetes Ecosystem (JKE)の紹介
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 関連記事 マイクロサービスを支えるインフラアーキテクチャ (AWS Dev Day 2019登壇資料) ECSデプロイツールを公開しました ECSにおけるログの取り扱いを別ページに移動させました 設計 基本方針 基盤を設計する上で次のキーワードを意識した。 Immutable infrastructure 一度構築したサーバは設定の変更を行わない Infrastructure as Code インフラの構成をコードで管理 (Terraformを採用) Serverless architecture 無駄にサーバを増やさない アプリケーシ
こんにちは。インフラエンジニアの光野です。 弊社ではネットワークの構築と管理にAWS CloudFormationとAWS OpsWorksを導入しました。 本記事では、その効果と導入に際しての工夫について紹介いたします。 目次 Before / After 効果 CloudFormarionとは CloudFormation or Terraform OpsWorksとは SSH/sudo管理 CloudFormationとOpsWorksの役割分担 CloudFormationテンプレートの分離方針 OpsWorksマルチレイヤーによるインスタンスの管理 OpsWorksでのdry-runとdiff YAML版CloudFormationでOpsWorks（Chef）を定義する場合の注意点 まとめ Before / After CloudFormationとOpsWorksを導入するま
dots. Conference Spring 2016 ゲーム開発の裏側 http://eventdots.jp/event/580344
Private content!This content has been marked as private by the uploader.
This document summarizes a microservices meetup hosted by @mosa_siru. Key points include: 1. @mosa_siru is an engineer at DeNA and CTO of Gunosy. 2. The meetup covered Gunosy's architecture with over 45 GitHub repositories, 30 stacks, 10 Go APIs, and 10 Python batch processes using AWS services like Kinesis, Lambda, SQS and API Gateway. 3. Challenges discussed were managing 30 microservices, ensur
Muninはオープンソースのリソース監視ツールであり，様々なサーバリソースの取得やグラフ化を行う事に特化しているツールである。 死活監視だけではなく，何故，リソースも監視する必要性があるのか。今回は，Muninユーザ会の前佛雅人が，自身のホスティング業務における監視体制や， 運用サポートの様子など実例を交えながらMuninの使いどころを紹介する。そして，クラウドコンピューティング時代における監視体制の目指すべき方向について考察する。 日時：2013年1月18日（金）18:00～ 会場：産業技術大学院大学 433教室 http://pk.aiit.ac.jp/index.php?InfoTalk%2F20130118
仕事でちょっくら12台のHDDを使ったRAIDアレイを組むんだけど、その折にちょうどTwitterで「RAID-1+0にしないとRAID-6とか怖くて使えませんよ！」というウソ八百な内容のWebページのURLを見掛けたので、いいかげんそのような迷信が消え去ってもよかろうと思って書くことにした。 1重ミラー設定のRAID-1+0は安全性においてRAID-6に劣る。ただし、正しく運用されている場合に限る。*1 知っている人はずっと前から知っている事実ではあるんだけど、某巨大SIerなんかでも高い方が安全に決まってる的な残念な脳味噌の持ち主がいっぱいいて「いやあデータの安全性を考えるとRAID-1+0」とか考えもなしにクチにし、そっちの方がディスクがいっぱい売れて嬉しいストレージベンダーもニコニコしながら否定せず売りつけて去っていくといううわなにをす(ry まあそんな感じで。ちなみに正しくない運
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
