ビルの来客システムと Slack を連携させたら便利すぎてヤバい - SmartHR Tech Blog
こんにちは、コーポレートエンジニアの yamashu (@yamashush) です。 本記事では、ビルの来客システムと Slack を連携させてみた話を書いていきたいと思います。 なにが課題だったか 弊社は2019年4月に六本木にオフィスを移転しました。 SmartHR 新オフィスの行き方 移転前にいたビルと比較して建物規模が大きくなり、1階にはフラッパーゲートが設置されています。ゲストの方の入館には、事前にお知らせしたワンタイムコードで入館証を発行していただくようになりました。 ワンタイムコードはビルから提供される 専用の Web システムで発行することになるのですが、これがなかなか 煩雑な作業 なのです。 サイトを開いて、ログイン等の前動作が必要 申請時の必須入力項目が10個くらいある 申請完了後にその場でワンタイムコードが確認できない（2〜3分後にメールで申請結果が届く） 移転前に
AWSのEBS Provisioned IOPSからEBSについて妄想する - プログラマでありたい
以前、EBSの内部構造を調べていて「結構知らないAmazon EBSの細かい話。主にEBSのネットワークの構造について」という記事を書きました。そこでEBSの性能はネットワークの帯域で制約される旨を書きました。すると、@namikawaさんに次のような指摘を頂きました。 このsh2さんのブログにも書いてあるけど、QEMUなりcgroupのレイヤでの制限に近いやり方なのかなぁと思っています。ただの想像ではありますが。d.hatena.ne.jp/sh2/20121217 確かにネットワークが性能の制約にはなりうるけど、ネットワークだけではProvisioned IOPSのようなIOPS単位での性能の制御は出来ないなぁと疑問に思っていました。気になったので、EBS絡みの性能測定や考察・Tipsを読んでみましたが、まだまだ解らない所だらけです。それでも、今回得た情報を元にProvisioned
Amazon EBSのGeneral Purpose(SSD)雑感→3000PIOPSの100GB(io1)より3000IOPS Infiniteの1000GB(gp2)のほうがおトク！ - yoshidashingo
cloudpackエバンジェリストの吉田真吾（@yoshidashingo）です。 gp2に関するチラ裏な考察です。 OS起動の高速化によるアジリティの強化 OS起動時に、Linuxで7,000I/Oくらい、Windowsでは70,000I/Oくらい使うんだ http://t.co/Jg5GRGbFO2— Shingo(吉田真吾) (@yoshidashingo) 2014年6月20日 AWSの公式発表の中で参考値として以下のような記述があります。 "典型的なLinuxの起動にはだいたい7,000 I/O操作が必要で、Windowsの起動には、だいたい70,000のI/O操作が必要でした。Magneticボリュームから同じ容量のGeneral Purpose (SSD)ボリュームにスイッチすることで、Windows 2008 R2の典型的な起動時間はおよそ50%短縮されます。" AWS N
周回遅れで、SSDベースの新しいAmazon EBSの話 - プログラマでありたい
少し前ですが、AWSのサービスに重大なアップデートがありました。ストレージサービスであるEBSに新しいサービスラインナップが追加され、General PurposeというSSDベースのサービスが利用できるようになりました。すでにyoshidashingoさんが色々考察しているので改めてまとめる必要もないですが、自分の中の整理のためにまとめてみます。 EBSのラインナップと価格体系 2014/06～ 今回追加されたのは、General Purpose(gp2)です。従来のスタンダードEBSはMagneticという名前になり、Provisioned IOPSは、io1という略称になりました。 東京リージョンで利用例 サービス名 ベースラインIOPS Max IOPS 価格体系 General Purpose (SSD) 3(IOPS)×GB 3,000(burst) $0.12 1 か月にプロ
結構知らないAmazon EBSの細かい話。主にEBSのネットワークの構造について - プログラマでありたい
先日、EBS（Elastic Block Store）のとある状況下での挙動について正確なところが知りたくて、改めて調べていました。その中で、AWSマイスターシリーズ ReloadedのEBS版を見つけたのですが、これが良い資料でした。今までEBSのネットワーク部分についてどういう構造になっているのか、正確に把握しませんでした。資料を読むことにより構造が解り、ボトルネックが発生した時にどう対処すればよいのか、より掴みやすくなりました。簡単にまとめてみたいと思います。 EBSの全体像 まずはEBSの基本構造です。当たり前といえば当たり前ですが、EBSはEC2ではなくその下のレイヤーのハイパーバイザにアタッチされます。アタッチ後にOSから認識させるという形になります。また接続の方式としてはネットワーク型ですが、利用者はネットワークを全く意識せずとも使えるようになっています。（SecurityG
AWSのAZの割り当ては、アカウントごとに違うという話 - プログラマでありたい
先週の金曜日（2019/8/23）に発生したAWSの東京リージョンで大規模な障害が発生しました。障害の内容は、一つのAZで空調設備の問題からEC2インスタンス並びにEBSに問題が発生したという事象です。詳細についてはAWSから発表があるので、そちらをご参照ください。 aws.amazon.com 障害の最中にTwitterのタイムラインを見ていると、単一AZ障害ではなく複数のAZで障害が発生しているのではないかという観測が多く見られました。障害としては、AWSの発表通り単一AZ障害です。では何故多くの人に勘違いされたのでしょうか？理由は2つあります。 AZの割り当ては、アカウントごとに違うという事が知られていない マルチAZ構成にしていても、単一AZの障害の影響を受ける ここでは前者のAWSアカウントの割り当ての話を説明します。 あなたが見ているap-northeast-1aは、私が見てい
マルチAZ構成で単一AZの障害の影響を受けるのは何故か？ - プログラマでありたい
昨日の「AWSのAZの割り当ては、アカウントごとに違うという話」で宿題として残した、マルチAZ構成で単一AZの障害の影響を受けるのは何故かという問題について考えてみます。キーワードはELBです。 前提としてのELBの実装（の予想） マルチAZ構成での障害発生原因を検討する前に、まずELBの実装について考えてみましょう。5年ほど前に書いたELBの挙動からみる内部構造の推測です。 blog.takuros.net 旧ELB（CLB）をもとに書いていますが、ALBでも大きく変わらないと思います。要点としては、ELB自体は、AWSが管理するEC2インスタンス上で稼働し、バランシング先のAZにそれぞれ配置されているということです。図ではELBインスタンス（仮称）として表しています。そして、ELBインスタンスへの振り分けはDNSの名前解決で実現している点です。このアーキテクチャは私の個人的な予想ですが
Amazon Elastic Load Balancing (ELB)の内部構造および拡張・障害時の動き - プログラマでありたい
諸般の理由により、AWSの各サービスの挙動を改めて復習中です。まずは、Amazon Elastic Load Balancing 、通称ELBについてです。ELBの内部の動作については、公開されている公式ドキュメントが割とあります。是非一度しっかりと目を通しておくとよいですよ。少なくともAWSマイスターシリーズのELBについては、読んでおくべきです。簡潔にかつ詳しく説明されているので、理解が格段に進むでしょう。というところで、現段階で私が理解しているELBのアーキテクチャをまとめてみました。 ELBの内部構造 ELBは、ELBエンドポイントとELBインスタンス（仮称）によって構成されます。ELBインスタンス（仮称）の正式名称は知らないので、その名前で呼ぶことにします。ELBインスタンスには、グローバルIPが付与されます。ELBエンドポイントは、myLB-xxx.elb.amazonaws.
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
【5分でOK‼️ナスの中華風】超簡単なのにびっくりする美味しさ！【Q&A、つくれぽ付き】