Katoです。 第5回までで、AWSとのソフトウェアVPN接続を確立しました。 AWSではNICのプロミスキャスモードが使えないということ、それ故に複数のSoftEther VPN Serverを拠点間接続することができないということは序盤で説明した通りです。 この制約はソフトウェアVPNにとって天敵とも言えるのですが、そんな状況下でも多数のVPN接続を確立して複雑なネットワークや高負荷な状況を考慮することは可能なのでしょうか。 今回はVPN接続数を増やすためにどう対応すべきか、考えてみましょう。 本来であれば… 本来であれば：つまりオンプレであればの話ですが、ソフトウェアVPNを用いてサーバ:クライアント=1:膨大の接続を確立する場合の負荷対策として、例えば次のようなアプローチを試みます。 もちろんAWSはオンプレではありませんので、オンプレでの常識が全て通用するとは言えません。 しかし

こんにちは、onprepack の津村です。 （※onprepack = 最近cloudpack社内で流行ってる単語。） 地元のスーパーで柿が売られているのをみて、秋を感じています…。（しみじみ VPCのプライベートサブネットに、VPNから乗り込む。 最近はGoogleAppsやサイボウズをはじめとして、グループウェア製品は、インストールタイプからSaaSに移行しつつあります。 インターネット上から誰でもアクセスでき、サーバを用意する必要が無いSaaSでの提供は、ビジネス上のコストを上手に下げてくれる効果があります。 しかし、一方で会社によっては、秘伝のタレのごとくコードを継ぎ足し作ったグループウェアから乗り換えられない（しかもスパゲッティでメンテできない）といった状況から、ミドルウェアの脆弱性やハードウェアの寿命を放置、もしくは場当たりのメンテナンスで延命している場合もあります。 例えば

はじめに こんにちは植木和樹＠上越妙高オフィスです。クラスメソッドではリモートワークが盛んで、多くの人が自宅やコワーキングスペースで仕事をしています。 特に台風の日は交通機関の乱れが予想されるため自宅勤務に切り替え、作業を行なう方が多いようです。 ただリモートワーク中でも、どうしても社内のデスクトップPC等にアクセスしなくてはならないケースがあります。 そのため会社ではVPNサーバーを用意し、リモートから接続することで作業ができるようにしてあります。 背景 これまでVPNサーバーは本社サーバー室に設置していました。しかし諸々の事情によりリプレースを行なうことにしました。 VPNサーバーの保守切れ 社員数が多くなりリモート接続ユーザーも増えた（ライセンス、パフォーマンスが足りない） 物理サーバーだとメンテナンスが現地にいるメンバーしかできない（年一回のビル停電など） そこでリプレースと合わせ

はじめに こんにちは、中山です。 SQSを利用したWorker構成はAWSのアーキテクチャとしてよく利用されていると思います。SQSのメッセージにジョブを登録しておき、それを監視するWorkerで非同期に処理をさせるという仕組みです。 とてもシンプルかつ安定性のある「枯れた」アーキテクチャです。が、みなさんはどうやってテストしているでしょうか。この場合の「テスト」とはメッセージが溜まった場合にWorkerが本当に処理を実施してくれるのか事前に検証したいという意味です。 一応AWS CLIには send-message-batch という1つのAPIで複数のメッセージを作成するサブコマンドが用意されています。ただ、あまり使い勝手よくないような…とはいえ、AWS SDKでスクリプト書くのも面倒です。 こういった要望に対して今回ご紹介するwrkを使うと解決できそうです。wrkとは「モダン」を謳う

こんにちは、Retty.Inc ソフトウェアエンジニア兼データサイエンティストのchie（@chie8842）です。 好きなたべものは焼肉とみかんです。 現在Rettyでは、次世代分析基盤を構築しています。Rettyでは、サービス拡大に伴いログの急増や分析需要の拡大が見込まれるため、高いスループットとコストパフォーマンスを両立する、スケールするアーキテクチャ設計が求められています。 今回は、こうしたスケールするアーキテクチャ設計の実現のために理解しておくべきDWHのコア技術の一つである、カラムナフォーマットに焦点を当てて紹介します。 はじめに - カラムナフォーマットとは カラムナフォーマットとは、データベースの分析用途に利用されるファイルフォーマットの種類の一つです。大量のデータを扱う際に効率的に圧縮してストレージコストを下げたり、計算時に必要なデータだけを取り出して計算コストを小さくで

ビルドやテストなどの一連の作業をJenkinsで自動実行することを考える。 通常これらのジョブはJenkinsのmasterやslaveで実行されることになり、ビルドに必要な環境構築（例えばjavaのインストールやmavenのインストール）はJenkinsのmasterやslaveに対して、事前に行うことになる。そして一度環境構築したサーバは長いこと使われる。 そうなると、同一サーバで複数バージョンのjavaを入れる苦労をしたりディストリビューションの差に基づくLinuxコマンドのあるなしに翻弄されたり、ローカルにしかないファイルを参照してそのうちジョブが動かなくなったりする。 これを解決するための手段としてビルド〜テストをDockerコンテナ上で実行しようという例は多くみられ、以下の記事が導入検討の参考になる。 www.buildinsider.net www.slideshare.ne

こんにちは、アメブロのフロントエンドエンジニアのときです。 アメブロでは2017年4月に、PC/SPブラウザの閲覧面のhttps化対応を行いました。 今回は、大規模サービスにおけるhttps化のフロントエンドの対応についてお話しさせていただきます。 ※現在は、https、httpどちらからでもアクセスができる状態で、徐々にhttps一本に移行し、「常時https化」を目標としています。 https化って何がいいの？ まず、既存のサービスをhttps化することで、サービスやユーザにはどういった影響があるのでしょうか。 メリットとデメリットをかいつまんでご説明します。 メリット セキュリティ強化、信頼性アピール SEO向上 最新の技術を取り入れることができるようになる セキュリティ強化、信頼性アピール 直接的なメリットとしてはやはり、HTTPS通信のみでサイトを配信することによる、セキュリティ

新しい技術が出てきたとき、大多数の若い人よりも圧倒的にスピーディーに使いこなすおっさんは珍しくない。 新技術を習得する能力は、年齢よりも、「スキルを獲得するために必要なスキル」、すなわち「メタスキル」に大きく依存するからだ。 たとえば、ある開発ツールを導入すべきかどうか若い人に相談されたので、「まず、ドキュメントを読もう」と言ったら、「ドキュメントを読んでもよくわからなくて。。」と言う。ググったらすぐに公式サイトの至れり尽くせりのドキュメントが出てきたので、「これ読めばいいじゃん」と言ったら、こんなに大量の英語のドキュメントを読むのは無理だと言う。 あるいは、AIを導入するという話になったとき、「AIがよく分からないので教えて欲しい」と言ってきた若い人に、良質の入門書を勧めたら、数式が分からないので読めないのだという。数式の読み方を教えてみたら、数式以前に、そこで使われている数学概念自体を

Amazon Web Services ブログ AWS CodeBuild と HashiCorp Packer を用いた AMI ビルダーの構築方法 独自の アマゾン マシン イメージ を作成し維持することは、運用とセキュリティにおけるベストプラクティスです。インフラストラクチャをコードとして維持することもまたベストプラクティスの1つです。そのため、Amazon EC2 インスタンスを素早く起動するために AMI を作成し設定する、といったことをスクリプト化するための自動化ツールを利用することには価値があります。 公開する2つの記事の最初にあたるこの記事では、AWS においてプログラマブルに AMI を作成するために AWS CodeBuild を使用します。AMI 生成の一部として、OS のパッチを適用し、バナーステートメントを設定し、よく使うソフトのいくつかをインストールし、将来的な

3. 自己紹介 ● MySQL サポートエンジニア – 日々のしごと ● トラブルシューティング全般 ● Q&A 回答 ● パフォーマンスチューニング など ● ライフワーク – 自由なソフトウェアの普及 – 趣味はリカンベントに乗ること ● 最近は執筆と子育ての日々・・・ ● ブログ – 漢のコンピュータ道 – http://nippondanji.blogspot.com/ 4. アジェンダ ● MySQL の性能解析の基本 – チューニングの基本 – スロークエリログ、 SHOW GLOBAL STATUS 、 SHOW ENGINE INNODB STATUS 、 SHOW PROCESSLIST 、 EXPLAIN – 基本的なパラメーターチューニング ● モダンなツールを使いこなす – パフォーマンススキーマ（ MySQL 5.5~ ） – ダイジェストサマリテーブル（ MyS

Netflixのパフォーマンスエンジニアである筆者からの、topコマンドなどで表示されるCPU使用率(%CPU)は、いまや本当の使用率を表しておらず、チューニングなどのための指標として使えないという指摘。なぜそうなってしまったのか、何を見れば本当のCPU使用率がわかるのかをわかりやすく解説した記事。 私たちみんながCPU使用率として使っている指標は非常に誤解を招くもので、この状況は毎年悪化しています。CPU使用率とは何でしょうか？プロセッサーがどのくらい忙しいか？違います。CPU使用率が表しているのはそれではありません。私が話しているのは、あちこちで、あらゆる人たちに、あらゆる監視製品で、あるいはtop(1)でも使われている、"%CPU"という指標のことです。 あなたの考えているであろうCPU使用率90% : 実際 : "stalled"(訳注 : 以下ストールと言う)とは、プロセッサーが