突撃！隣の開発環境 パート12【Treasure Data編】 in シリコンバレー | DevelopersIO
こんにちは！しんやです。今回はおおはしりきたけが書き連ねている人気シリーズ『突撃！隣の開発環境』に乗っかる形で私もこのシリーズエントリを書かせて頂きたいと思います。 突撃！隣の開発環境とは 技術事例やノウハウなどは、ブログや勉強会などで共有されることが多いと思います。しかし、各社の開発環境や開発体制などは意外と共有されていないこと多いと思います。ノウハウの流出になるかもしれませんが、それ以上に、より良い開発を目指している会社さん同士で情報交換を行い、良いチーム、良いプロダクトを作っていくという志の会社さんの為の情報共有のための企画になります。開発環境や開発体制なども技術領域によっても変わってくると思いますが、この突撃！隣のシリーズでは様々な会社さんのイケてるツールの使い方や、仕事が捗る開発体制についてインタビューを行っていく予定です。 Treasure Data社紹介 今回第12回目として
AWS News Blog
Build RAG applications with MongoDB Atlas, now available in Knowledge Bases for Amazon Bedrock Foundational models (FMs) are trained on large volumes of data and use billions of parameters. However, in order to answer customers’ questions related to domain-specific private data, they need to reference an authoritative knowledge base outside of the model’s training data sources. This is commonly ac
microインスタンスはlimitかけると大きくパフォーマンスが向上する（※再追記あり） - アルパカDiary Pro
※2014/07/02 T2インスタンスタイプとの比較 を追記しました。 ※2014/03/13 他インスタンスタイプとの比較／m3.mediumの検証 を追記しました。 こちらの記事の二番煎じです。 cgroupで、お手軽CPU使用率制限 なるほど。 リソースにLimitかけるとstealを防げるためパフォーマンスも上がるというわけですね。 どのくらい変わるのか実験してみました。 cgroup前準備 sudo yum install libcgroup sudo chkconfig cgconfig on sudo service cgconfig start cgroup設定 上記参考URLとほぼ同じ設定です。 実行時はcpu.cfs_quota_usを変動させて比較してみました。 sudo vi /etc/cgconfig.conf # 以下を追加 group limittest {
Amazon S3における「フォルダ」という幻想をぶち壊し、その実体を明らかにする | DevelopersIO
よく訓練されたアップル信者、都元です。Amazon S3について細かい説明は不要かと思いますが、要するにファイルストレージです。HTTPベースでファイルをアップロードでき、そしてダウンロードできるサービスですね。 古くから、データはシリアライズされた形式でファイルという単位に格納し、管理されてきました。ローカルマシン内でファイルを管理する仕組みがファイルシステムで、その多くにはフォルダという階層構造を扱う仕組みが備わっています。 Amazon S3も、Management Consoleによってフォルダを作成し、その中にさらにフォルダを作成したり、ファイルを格納できたりします。しかし。 Amazon S3には実はフォルダという概念は無い のです。Amazon S3の基礎技術は、単純なKVS（Key-Value型データストア）でしかありません。例えば下記のようなフォルダ（と我々が認識している
Terraform + GitHub + CircleCI + Atlasを利用してAWSの操作を自動化した - Glide Note
TL;DR Terraform + GitHub + CircleCI + Atlas を用いてAWSの操作を自動化した 各ツールの役割は下記のような感じ Terraform => インフラへの変更ツール GitHub => .tfファイルのバージョン管理 CircleCI => CI、Terraformをawsに対して実行 Atlas => インフラの状態を記録するterraform.tfstateの管理 インフラの継続的デリバリー - naoyaのはてなダイアリーにて、言及されていた範囲(Route53の変更、Chefの適用)をAWSの操作全体に拡大した 背景 今までの問題点 AWSの各種操作がブラウザからポチポチ業… 手作業なので誤操作に気づきにくい。事故りやすい インフラの実構成がバージョン管理出来ていない ちなみにRoute53に関してはroadworkerを用いてコードで管理済
【AWS】VPC環境構築ノウハウ社内資料 2014年4月版 | DevelopersIO
よく訓練されたApple信者、都元です。 以前、【AWS】VPC環境の作成ノウハウをまとめた社内向け資料を公開してみるという記事を書きましたが、そこから半年経ち、状況も変わって来ましたのでアップデートを行いたいと思います。 以前のエントリーを読んだ方は、忙しい場合は下記の「2013年10月版からのアップデート」だけを読むといいかもしません。 VPCを利用する理由 AWSは、あらゆる規模のプロジェクトに対応するインフラを提供しています。前述のサーバ数千台規模のプロジェクトしかり、1台構成しかり。大規模プロジェクトであれば当然、オンプレミスと同様にネットワークインフラについての設計を綿密に行う必要がありますが、では、中小規模のプロジェクトにおいてはネットワークの設計をする必要はないのでしょうか。 AWSでは、VPCという「ネットワーク環境」を構築するサービスを提供しています。しかもVPCの利用
AWS 対応した GitHub Enterprise v2 へスムーズに移行した話 - クックパッド開発者ブログ
技術部 id:sora_h です。今回は v2 より AWS 上での運用に対応した GitHub Enterprise を、オフィスにある既存の環境から AWS へスムーズに移行した話について説明します。 GitHub Enterprise v2 GitHub Enterprise (以下 GHE) とは、github.com を自前の環境で運用できるアプライアンスです。クックパッドでは主に GHE 上で開発を行っています。 従来まで GHE の実行環境として VMware vSphere, VirtualBox 上の実行しかサポートされていませんでしたが、11 月にリリースされたアップデート v2 より、AWS での実行がサポートされました。 クックパッドでは全面的に AWS を利用していますが、いままで GHE を AWS 上で動作させる事はできませんでした。そのため、オフィス内に E
Amazon VPC Peeringの技術的考察と留意点 | DevelopersIO
大事なことなのでもう1回言います。今回のVPC Peeringは、2つのVPC間のL3ネットワーク通信を提供します。 ...言わんとするところ、伝わったでしょうか。伝わりにくいですかね?(笑)説明としては上の文章でいいのですが、思い浮かぶイメージと実現できることにはそれなりに隔たりがあるので、そこを理解いただきたいというのが今回のエントリーの狙いです。VPC Peeringの仕組みを自分なりに考察(≒妄想)し、そこから見えてくる留意点を紹介してみます。以下に要点をまとめます。 ルーティングの設計はユーザーが行う。 Peeringなので、2VPC間以外のルーティングを取り持つことはできない。 Peering経由でIGW/VGWは利用できない。 ルーティングの設計はユーザーが行う Peeringの設定は、VPCの[Peering Connections]画面で、作成・管理します。ただ、このPe
visualops.io
Buy this domain. visualops.io 2021 Copyright. All Rights Reserved. The Sponsored Listings displayed above are served automatically by a third party. Neither the service provider nor the domain owner maintain any relationship with the advertisers. In case of trademark issues please contact the domain owner directly (contact information can be found in whois). Privacy Policy
Amazon EC2インスタンスに簡単にSSHできるようになるツールec2sshを公開しました - 昼メシ物語
みんなが大好きなクラウドホスティングサービスのAmazon EC2ですが、インスタンスをバンバン立てたり落としたりしていると、ホスト名の管理が面倒になってきますよね。たとえば「さっき立てたインスタンスにSSHしたい！」と思ったら、consoleをひらいて、「ec2-xxx-xxx-xxx-xxx.compute.us-west-1.compute.amazonaws.com」なPublicDNSをターミナルにコピペして…みたいな面倒な事をやってしまいがちです。 これを避けるためには、~/.ssh/configをマメに更新したりするといいのですが、これはなかなか面倒な作業です。インスタンスは一旦StopしてRunし直すと、IPが変わってしまいますからね。 そこでec2sshの登場です ec2sshは、インスタンスのNameタグからホスト名を生成して、~/.ssh/configに書きこむツール
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
スタートアップにjoinして安心して眠るためにやった5つのこと
Amazon Kinesis（ストリーミングデータをリアルタイムで収集、処理、分析）| AWS