「レプリケーション」を含む日記 RSS

はてなキーワード: レプリケーションとは

2024-02-10

https://softantenna.com/blog/jujutsu-replace-git/

jjなあ

女性自身が引っかかりそうな名前

と思ったらjjはもう月刊は終了してました

そっかー


jujutsuそのものに関してはなんかイマイチだな

特徴が列挙されてるけど、そんなところは特に困ってねえとしか言いようがない

安全な同時レプリケーションCIサービス業者とかは便利だったりするのかもしれん

それよりLFSシームレス統合してほしい

2023-03-03

IOWNという呪い

NTTが満を持して出してきたIOWNというネットワークサービスが予想通りがっかりだったので解説しておく

IOWNとは

そもそもIOWNって何?っていう話については恐らくNTT社員でも誰一人答えられないので割愛したいが

発端は電気によるネットワークルーティング限界が来ていることから始まっている

これは性能的な限界でもあるのだが消費電力の限界でもある

このままではルーター1機に原発1台という時代になりそう、というのはよく言われた話だ

IOWNは光を使ったルーティングを行い、End-To−Endで電気を使わずに光だけで通信すること(All-Photonics Network: APN)が構想の発端である

電気によるルーティングには遅延が発生することもあって「大容量・低消費電力・低遅延」の3つが特徴として挙げられる

大容量

大容量かどうかはネットワーク契約帯域を見ればすぐに分かる

1Gbpsしか無かったのに10Gbpsが登場すれば「大容量になった!」となるだろう

IOWNは100Gbpsを提供してくれる

ちなみに今でも企業向けに100Gbpsの専用線サービス存在している

また、NTT東西は昨年400Gbpsのサービスも開始した

なのでIOWNは何も大容量サービスではないのだ

ただ、IOWNにおけるNTT側の性能目標はIOWN1.0で従来の1.2倍なので

まぁ実効速度として1.2倍という意味だと思えばこの100Gbpsも妥当かもしれない

また、IOWN2.0では6倍になるとのことなので600Gbpsが実現できるのであろう

ローンチで現行より劣っているのは残念に他ならないが安全側に倒したと思えば分からなくも無い

低消費電力

低消費電力は我々にはほとんど影響がなく、NTT社内の話なので「知らんがな」という感じなのだ

ユーザーに影響があるとすれば価格への転嫁ぐらいであ

低消費電力でランニング費用を抑えることができているはずなので提供価格も下がるはずである

さて、IOWN1.0の提供価格は月額198万円とのことである

現在提供されている100Gbpsの専用線サービスも198万円である

これも資料を見るとIOWN1.0では1.0倍とのことなので妥当価格である

IOWN2.0では13倍(倍とは?)とのことなので価格も大幅に下がってくれるだろう

逆に現状では一切電力効率は良くなっていないのに同価格で出してきてくれていることは良心的ですらある

低遅延

ということで大容量・低消費電力に関しては現行と同等もしくは劣っているIOWN1.0だが

遅延に関してはIOWN1.0で1/200を目指している

これはIOWN4.0まで1/200なのでこれより下がることはなく、逆にIOWNの目指している低遅延をローンチから体験できるということになる

さて、低遅延になって誰が嬉しいのかはさておき、現状では東京大阪間で15msぐらいである(往復)

これが1/200になると75μsとなるのだが、東京大阪間の光の伝搬遅延だけで5msはあるのでいくらIOWNでも光の速度は超えられない

なので機器遅延の10msのみが1/200となるとすると50μsとなり、往復遅延は5.05ms、ほぼ5msぐらいになる

実際に実証実験では8msを実現できたとのことなので大変速くなっているのだろうが

15msが8msになったのを「1/200」と言われるのはモヤッとする

そのせいなのか、「IOWNが提供できる低遅延の価値」という資料では、「映像処理やコーデックに関わる部分を省略できるので実質1/200」という言い方に変えている

まりは大容量であることを活用して非圧縮送信すればコーデック部分の処理遅延を減らせるとの主張である

コーデックの遅延は製品にもよるが200〜800msぐらいある

また、超低遅延のコーデックなら10msを実現できるらしい(使ったことはないが)

伝送遅延なんて無視できるほどコーデックの遅延は大きいので非圧縮であれば確かに遅延が1/200になるような体験ができるだろう

ただしそれは従来の100Gbpsネットワークでも実現できる

特にこの手の非圧縮による低遅延化というのは10Gbpsのネットワーク研究する際によく使われた方便

4K映像を非圧縮で送ると6Gbps消費するため10Gbpsにしましょう、という論法なのだ

それが今の時代では、8K圧縮は72Gbps消費するから100Gbpsにしましょう、という話なのである

ちなみに8Kで120Hzなら144Gbps必要なのでまだまだご飯を食べられるのだろう

問題なのはこの非圧縮リアルタイム映像伝送ほとんど使われていないということである

コーデック進化することでコーデックにかかっている遅延は無視できるようになり

特に高精細映像であるほど圧縮率が高くなるのでネットワーク負荷のコストの方が問題になるのだ

なので実際の利用で非圧縮伝送はほとんど用いられておらず、主にネットワーク試験で用いられているのが現状である

まぁこの辺はさておいたとしても、結局はIOWNの実現した大半の価値である低遅延の部分は従来でもやっている技術であって真新しいことではない

7ms価値はあるか

それでも従来の100Gbpsでは15msだった遅延が8msになったとなれば1/200とまではいかなくても価値があるだろうか

遠隔での演奏実験した際の記事が興味深く、8msの遅延ということは3m程度離れて演奏したことになる

まりは15msなら5m離れていることになる

この2mに価値があるのだろうか

また、人間の脳のクロック間隔は30msであるという研究結果がある

まりは30msより速くしても人間認知できないのだ

15msが8msになることで人間に対して何か価値があるのかは甚だ疑問である

問題なのはIOWNではこれ以上遅延が短くなることはなく、既に限界ということだ

光の速度の限界なので当たり前ではあるのだが

限界まで突き詰めても我々のネットワークを介した体験は一切変化しないということを証明してしまったのだ

e-Sportsとの相性

普通演奏では低遅延にほぼ価値がないので、エクストリーム分野のe-Sportsとの相性を模索しているように見える

かにe-Sportsをやっているような人たちは60fpsの1フレームを競っていると言われている

認知できているかは怪しいものだが)

そのためIOWNもe-Sports会場を繋ぐような使い方を例としてあげているのだが

そもそもe-Sportsゲームソフトウェアは5msだとか8msとかの中途半端な遅延を考慮してゲームを作っているのだろうか

同じL2の下で対戦を行うことが前提なら普通は2〜3ms程度の遅延を前提に設計するので5msでは遅い

逆に遠隔での対戦を考えれば10ms以上の遅延もあり得るのでそのように設計するが

その場合に5msであっても得られるメリットは何もない

ジャンケンゲームを作るときに2〜3ms程度までなら同時に開示するが

10ms以上なら1秒待ってから開示するような作りになっていると思えば分かりやすいかもしれない

もちろんゲームによってはこの数ms価値が生まれ場合もあると思うが、あまり数は多くないように思える

IOWNの今後

結局のところ、IOWNは大容量かつ低消費電力、つまり低価格サービスとして進んで行くだろう

End-To-EndでIOWNが必要か、と言われると明確に答えはNOで

10Gbpsですら全然普及が進んでいないのに100Gbpsの大容量ネットワークそもそも必要ない

一方でデータセンタ間のインフラネットワークとしては非常に価値が高い

データレプリケーションなどを考えれば遅延など1msでも短い方が良いのだ

特に災害が多い日本では地理位置分散をさせることは非常に重要

そういったデータセンター間のネットワークとして大容量・低消費電力・低遅延なネットワークは非常にありがたいものとなる

こうしたインフラとしての重要性は明確に求められているのにもかかわらず

「IOWN」と標榜してまるで次世代ネットワークであるかのように喧伝しているのは、一体どのような呪いがかかっているのか興味深いところではある。

2022-11-30

anond:20221129085814

正直気持ちはわかる。

個人の実感としては、コンピュータサイエンス定義と関わるシステム要件によるとしかいえないかな。

例えばコンピュータサイエンスを、

アルゴリズム計算

OSの仕組み

DBの仕組み

分散システム理論合意形成とかサービスディスカバリとかレプリケーションとか障害リカバリとか)

CPUの仕組み

・並行プログラミング

TCP/IP

みたいな知識定義したとする。

toC向けのスタートアップフェーズプロダクトとかだと正直なくても回る実感はあるし、実際テキトーに作られてるけどなんとか動いてるシステムはかなり見てきた。

でもある程度成熟してユーザ数もトラフィックもかなりあるみたいな状況だとこの辺の知識なしではお話にならない。

そういったプロダクトだとセキュリティ要件スケール要件がかなり厳しくなってきて、その観点なしに開発運用できないから。

正直ただ作るだけだったらライブラリフレームワークの使い方さえ覚えておけばなんとかなるけど、

大規模になればなるほど、効率的に作らないとコストがかかりすぎて大変だし、最悪動かない。

で、効率的に作るためにはこのあたりの知識はどうしても必要になるはず。

データ量的にO(n)とO(n^2)ではそれはそれは段違いになる。

2022-02-18

VMWare苦しい戦いしてるなー

まあVMWorldとかで10年以上人生の春を謳歌してきたからもう十分やろ

お疲れさん

マルチクラウド環境における5つの課題とは

VMware提案する、DRにも対応するマルチクラウドソリューション

昨今のCOVID-19流行への対応やDXを推進する中で、クラウドサービスの利用はビジネススピードの加速や柔軟なシステム運用効果的であり、従来のオンプレミス環境と併用するハイブリッド環境や、複数クラウドを利用するマルチクラウド環境が増えている。一方で、これらの環境を維持していくには課題も多く、セキュリティリスクも増大してしまう。ここでは、こうした課題解決するVMwareソリューションを紹介する。

マルチクラウド環境における5つの課題

COVID-19流行への対応やDX(デジタルトランスフォーメーション)のためのビジネス変革が進む中で、ビジネススピードの向上やニーズに対する迅速で柔軟な対応がこれまでになく求められている。これらを実現するために、アプリケーションの変革やクラウドへの移行が加速している。

多くの企業が、「ビジネススピード対応できるモダンアプリケーション」や、「あらゆるクラウドデータセンター、エッジでビルドおよび実行が可能であること」、「エンタープライズクラスレジリエンスセキュリティ運用の実現とビジネス変革」がDXを実現するために必要であると考え、これらを実現するためにマルチクラウド環境活用が前提になってきている。

具体的には、Amazon Web Services(AWS)、Microsoft Azure(Azure)、Google Cloud Platform(GCP)といった複数パブリッククラウドサービスを併用し、適材適所で使い分けているのが現状であろう。しかし、マルチクラウド環境では解決必要課題存在する。その課題とは、「ワークロードのシームレスな移行・連携」、「クラウドごとのスキル習得」、「運用管理簡素化」、「セキュリティリスクの低減」、「最適なコスト管理」の5つである。この5つがクラウド利用の理想現実ギャップとなっており、これらを意識して進めていく必要がある。

マルチクラウド環境における5つの課題

特にマルチクラウド環境適材適所で使う場合クラウドごとに利用する技術が異なるため、設定項目や内容に違いがあり、その設定ミスによるインシデントも発生している。重大な影響を及ぼす場合もあるため、それぞれのクラウドを扱う際のスキル重要になる。

VMware Cloud on AWSの特長とメリット

こうしたマルチクラウド環境における課題解決するには、一貫性のあるクラウドインフラストラクチャ、および運用管理サービス重要ポイントとなる。例えばVMwareは、複数パブリッククラウドだけでなくオンプレミスを含むハイブリッドクラウド環境においても、仮想的なレイヤーを構築することで管理運用を一元化している。

VMware Cloud on AWSは、VMwareAWSが共同で開発したもので、AWSベアメタルサーバー上にvSphere、NSX、vSAN、vCenterを導入し、ホスト専有型のクラウドサービスとして提供するものだ。

VMware Cloud on AWSの特長

その特長は3つある。1点目は「VMware製品ベースとしたクラウドであること。VMware製品仮想化されているため、AWS世界にいながらオンプレミス環境で利用していたスキルセットや運用管理ツールを利用でき、新たなスキル習得する必要がない。

2点目は「シームレスクラウドに移行できる」こと。ワークロードをオンプレミス環境から無停止で移行することができる。アプリケーションを更改する必要もないため、クラウドに移行する時間コストリスクを大幅に削減することが可能だ。

3点目は「VMware管理を行う」こと。ハードウェアソフトウェアトラブル対応運用管理メンテナンス対応など、すべてサービスの中でVMware実施する。3カ月に一回の頻度で新しいリリース提供しており、ユーザー要件を反映しながら新たな機能を追加している。

最近アップデートの大きなものとして、日本で第2のリージョンとなる大阪リージョンを設置し、サービス提供を開始したことが挙げられる。例えば西日本地区データセンターを持つユーザーは、より低遅延でサービスを利用できるようになった。昨今は感染症流行地震の発生などによってBCPを見直すユーザーが増え、VMware Cloud on AWSリカバリサイトとして利用するケースも増えている。その意味でも、大阪リージョン活用度が高いといえる。

大阪リージョンサービス提供開始

VMware Cloud on AWSが選ばれる理由は、大きく3つ挙げられる。1点目が既存ノウハウ運用管理手法をそのまま踏襲できるという点。VMware製品ベースとしたクラウドサービスであるため、オンプレミス環境における管理者のスキル運用ノウハウなど、既存資産をそのままクラウド上でも活用でき、新たなスキル習得や、運用管理手法の大きな変更の必要もない。クラウドオンプレミス環境をvCenterから一元管理できる。

VMware Cloud on AWSが選ばれる理由

2点目が、規模に依存しないシンプルクラウド移行を実現できる点。ワークロードをそのままクラウド簡単に移行することが可能だ。VMware Cloud on AWSには標準でVMware HCXが含まれ、これはオンプレミスデータセンタークラウド間のネットワークをL2延伸する。ネットワークがつながった環境仮想環境VMをそのままマイグレーションできる。アプリケーションIPアドレスを変更することなく、無停止でワークロードを移行することができる。

3点目が、モダナイゼーションを推進して、ユーザーのDXの加速を支援できる点。まず、クラウドならではのインフラストラクチャとして、1顧客あたり最小2ホストから最大640ホストまで拡張できるが、俊敏性を兼ね備えて提供される。例えば、ホストの展開に1時間半程度、ホスト数を追加するのに15分程度と、オンプレミス環境ではありえないスピード感で環境を構築、提供される。

また、リソース最適化する機能提供される。ユーザーリソース使用状況に応じて、利用するホストの台数を自動的に増減させて最適化する。さらに、名前の通りにAWS提供する各種サービスとの親和性が非常に高いことも特長。VMware Cloud ENIと呼ばれる専用のインタフェースを経由して接続することで、低遅延で高速な環境を利用して各種のAWSサービスシームレス連携することができる。この面も同サービスの大きな強みとなっている。

クラウドスケールインフラストラクチャ

最近では、VMware提供するKubernetesディストリビューションであるVMware TanzuをVMware Cloud on AWS上で稼働させることが可能になった。これにより、短時間コンテナKubernetes環境が導入できるようになる一方で、ハードウェアソフトウェア管理はすべてVMwareが行うため、管理者はKubernetes環境に集中できる。

VMware Tanzuの概要

高まるDR環境へのニーズ安価に実現

VMware Cloud on AWSユースケースには、主に「オンプレミス環境クラウド移行」、「データセンター拡張」、「災害対策サイト」、「次世代アプリケーションプラットフォーム」の4つが多い。特に最近は、災害対策としての利用が増えているという。VMware Cloud on AWSリカバリサイトとして活用する際に強力なサービスとなるのがVMware Cloud Disaster Recoveryだ。

VMware Cloud Disaster Recoveryを利用すると、平常時には本番サイトデータクラウド上のストレージ領域レプリケーションしておき、万一DRイベントが発生した際に初めてVMware Cloud on AWS上にホストを展開し、保護していた仮想環境フェイルオーバーする。リカバリサイトとしてあらかじめ物理的なサイトを構築しておく必要がないため、大規模な初期投資不要となる。

VMware Cloud Disaster Recoveryの特長

このタイプオンデマンド展開型と呼ばれ、DRイベント時にホストを展開したタイミングリカバリサイトに対する課金が開始される。復旧後に仮想環境を本番サイトに戻すことで、ワークロードもフェイルバックでき、不要となったリカバリサイトリソースも削除され課金も停止される。なお、オンデマンド展開型のほかに、事前にホストを展開しておく事前展開型も用意されており、RTOを重視する場合には事前展開型が推奨される

また同サービスは、最近話題になっているランサムウェアへの対策にも有効だ。クラウドストレージ上に本番環境データバックアップする際には、リカバリポイントを長期的に保持することが可能である。このため、ランサムウェア攻撃に遭ってしまった場合、その直前の時点からリストアすることが可能となる。

マルチクラウド環境可視化するVMware vRealize Cloud

マルチクラウド環境では、各クラウドが複雑化し、サイロ化してしま可能性がある。クラウドごとに管理ツールや必要とされるスキルノウハウも異なるため、利用するクラウドが増えるほど複雑化、サイロ化の問題が大きくなり、その結果セキュリティリスクコストが増加してしまう。そこで有効解決策となるのが、クラウド環境をまたがって一貫性のある運用管理を実現できるVMware vRealize Cloudである

まず、VMware vRealize Operations Cloudは、VMware Cloud on AWSリソースだけでなく、他のパブリッククラウド上のリソースも一元管理できる。複数クラウド環境にまたがってデータ収集分析評価を行うことで、例えば常にパワーオフ状態仮想環境や、実体がない状態ディスクなどを検知された場合最適化していくことが可能。これにより、最終的にコスト最適化も図ることができる。

コスト運用最適化できるVMware vRealize Cloud

また、VMware vRealize Log Insight Cloudによって、複数クラウドを横断してログ管理できる。例えば、監視対象イベント通知をあらかじめ定義しておくことで、不正な行動を検知した際には管理者に通知し、適切な調査対応を行うことができる。セキュリティコンプライアンスの強化にも有効だ。

さらに、クラウド間のネットワーク可視化は、VMware vRealize Network Insight Cloudで実現できる。End to Endを含むネットワーク全体を可視化できるため、ネットワークに関するトラブルシューティングや、不審通信を洗い出すこともできる。また、アプリケーション通信も把握できるため、アプリケーションの移行計画にも活用できる。

今後、DXの推進を加速していく上で、必ずしもひとつ環境ひとつクラウドを利用するのではなく、マルチクラウド環境の利用が当たり前になっていくと考えられる。そこで直面する前述の5つの課題に対し、VMware Cloud on AWSそしてVMware vRealize Cloudの活用課題解決するだけでなく将来への有効投資となる。企業規模や業種に関係なく検討すべきソリューションといえるだろう。

2015-05-08

AWS入門書籍おしえてください

中小企業勤務のど素人です。平均年齢40歳くらいの昭和からある非IT企業です。

前任者が退職して、他に出来る人がいないという理由で、自社HPインフラ担当することになりました

個人でレンタルサーバーVPS契約してLAMP環境構築して、ごく単純なWEBサービスを公開していますが、

ググってでてきた手順を見よう見まねでやったので、基本を理解できてないので、怖いです。

UNIXの基本コマンドもおぼつかない感じです。

WEBサーバーDBサーバーファイルサーバーも一緒の1つのサーバーです。

DBレプリケーションもしていません。

会社サービスは、今までは会社サーバーを置いてやってました。

リプレースが大変なのと、AWSWEBサービス業界標準のようなので、迷うことなAWSにしていきたいです。

一人でやるのは怖いので、無理ですといったのですが、押しつけられました。

2015-05-07

AWS入門書籍おしえてください

中小企業勤務のど素人です。平均年齢40歳くらいの昭和からある非IT企業です。

前任者が退職して、他に出来る人がいないという理由で、自社HPインフラ担当することになりました

個人でレンタルサーバーVPS契約してLAMP環境構築して、ごく単純なWEBサービスを公開していますが、

ググってでてきた手順を見よう見まねでやったので、基本を理解できてないので、怖いです。

UNIXの基本コマンドもおぼつかない感じです。

WEBサーバーDBサーバーファイルサーバーも一緒の1つのサーバーです。

DBレプリケーションもしていません。


会社サービスは、今までは会社サーバーを置いてやってました。

リプレースが大変なのと、AWSWEBサービス業界標準のようなので、迷うことなAWSにしていきたいです。

一人でやるのは怖いので、無理ですといったのですが、押しつけられました。

2013-03-13

サーバ初心者Webサービスを公開するうえで考えたこと

だって自作Webサービス公開しました

http://www.radiosonde.net/

これまで他の人に用意してもらったサーバ自分プログラムを動かしたことはありましたが

自分自身で一からサーバをセットアップしたことはほとんどなかったので、いろいろとハマりました。

作業を進める上で困ったり考えたりしたことを書いていきます

ちなみにサーバ自体はさくらのクラウドOSにはCentOSを使用しているので、それ前提のお話になります

SSHファイヤーウォールの設定

最初サーバを起動してから速やかにSSHファイヤーウォールの設定を変更しました。

はてブなんかでも定期的に話題になっているのでおなじみですね。

SSHポートを22以外の別のポートに変更する

rootによるリモートログインを禁止する

パスワードログインを禁止し、鍵認証有効にする

・念のためrootパスワードを潰しておく

SSHHTTP(S)など、どうしても公開しなければならないポート以外は遮断する

SSHポートについてIP制限が行えるならば尚良い

さらっと書きましたが、設定をミスって自分自身もログインできなくなり、何度かOSの再インストールを繰り返しています

から気付いた事ですが、さくらのクラウドではクラウド管理画面のリモートスクリーン経由でローカルログインできるので

別にOSインストールしなくてもiptablesの設定を変更できたんですよね...

逆に言うといくらファイヤーウォールとSSHを設定しても管理画面にパスワードログイン環境が残ってしまうので

パスワード管理には引き続きしっかり気を使う必要がある。ということでもあります


Webアプリの動作が重い

httpd,php,mySQL,memcachedなど必要サービスインストール、設定し

作成したWebアプリプログラムを乗せて動かしてみました。が、動作が重いような...

開発環境ではさくさく動いていたのに、本番環境ではどのページ遷移ももっさりしています

abで計測してみたところ、開発環境のおよそ2分の1のスコアとなってしまいました。

開発環境が仮想2コアのメモリ1Gだったのに対し、本番環境が仮想1コアのメモリ2G

CPUの性能について半減しているのでそのせいかな、と思いつつ設定を見なおしていたところ

特に使っていないと思われたipv6を停止した途端にパフォーマンス改善されました。

ページ遷移に伴うもっさり感が解消され、abの計測結果も開発環境と遜色ない結果が出ています

デフォルト有効になっていたipv6の影響により余計な処理が走っていたのかもしれません。


サーバから送信したメール迷惑メールと判定される

パフォーマンス改善に喜んだのも束の間、会員登録などの処理でWebアプリからメールを送信したところ、Gmail宛のメールがことごとく迷惑メールと判定されるという事案が発生。

spfの設定を行なうメールの内容について吟味するなどの回避策を試してみましたが一向に改善されません。

試しにHotMailexciteメールアカウントに送信したところ、そちらではそもそもメールを受け付けてもらえずエラーコードが返って来る始末。

困り果てていたところ、エラーの内容からサーバIPがspamhousにスパム送信元として登録されていることが判明しました。

postfixホスト名の設定がデフォルトで「localhost.localdomain」などとなっており、それをそのまま使っていたためにGmailスパム送信元として通報してしまったようです。

設定を修正し、spamhousに解除依頼を提出。事なきを得ました。


KVSの変更

クラウドを利用すれば、サーバを停止することなく簡単な設定でスケールできるようになる。

と、自分勝手に思い込んでいたせいなのですが、消えては困るデータの一部をmemcachedに保存する実装を行なっていました。

実際のところさくらのクラウドではサーバを完全に停止しなければプラン変更を実施できないし

そもそもサーバが落ちたらどうするんだよ。ということで、急遽KVSを変更する必要に迫られました。

速度の低下が気にかかったため、いくつかの候補を実際に動かし

phpスクリプトから1万件のデータ読み書きを行うという形でmemcached比較してみたところ次のような結果に。

サービス1万件書込1万件読込
memcached 2.55秒 2.30秒
handlersocket 21.23 2.71秒
InnoDB20.23 5.10
kyotoTycoon 8.22秒 7.72秒

さすがに読み書きそれぞれmemcachedが最速ですが、読み出しについてはhandlersocketも負けていません。mySQLから普通にSELECTしてもmemcachedの2倍程度の時間しかからないという結果が意外でした。

しかしながら書き込みのほうではhandlersocketもmemcached10倍近くの時間がかかっており、少々速度的な影響が気になってきますmemcachedの倍のパフォーマンスを記録したという記事を見たことがあるので、設定、チューニングについて生かしきれていない部分があるのかもしれないとも思いましたが、知識が不足しているところで無理をすると問題が発生した時に対処できないと考え、候補から除外することとしました。

結局、今回の用途では読み込み処理より書き込み処理のほうが圧倒的に多いことも考慮し、kyotoTycoonを採用しました。実際の利用箇所に組み込んでabで計測してみたところ、だいたい30%程度のパフォーマンス低下にとどまっており、これなら許容範囲かと考えています

mySQLレプリケーションが止まる

実行系と参照系に分ける形でmySQLレプリケーションを行なっていたのですが、度々レプリケーションが停止する現象が発生しました。

一部のテーブルについて肥大する可能性が考えられたため、参照系に接続するプログラムで使わないテーブルをレプリケーションから除外していたのが原因です。

例えばtabelAをレプリケーションし、tableXをレプリケーションしないという設定にしたうえで

実行系でINSERT INTO `tableA` SELECT `value` FROM `tableX`などといったクエリを発行すると、参照系にtableXが無いためエラーが発生して止まってしまます

レプリケーションするテーブルを限定する場合プログラム側でも注意を払わないと危険です。当たり前ですが。

サーバ監視にmonitを使用

監視といえばcactinagios定番なのかもしれませんが、設定が複雑そうで尻込みし、monitを使用することにしました。

簡単な設定でloadaverageやメモリHDDの使用量をチェックできるほか

httpdmysqldなどといったサービスプロセス監視し、もし落ちていたら自動で起動してくれるので助かります

Webアプリの秘匿

パスワード保護を行うとしても、サイト全体の管理画面など自分しか使わないプログラムWeb晒しておきたくない。

というわけで、一部のWebアプリを秘匿する設定を行いました。

管理画面のWebアプリを9999番など閉じているポートに設置した上で、SSHを利用したトンネルを掘ります。といっても

ssh -t -L 9999:localhost:9999 user@xxx.xxx.xxx.xxx

上記のようなコマンド管理画面のWebアプリを置いたサーバログインするだけです。

ブラウザアドレス欄にhttp://localhost:9999/と打ち込めば、接続が開いている間のみアクセス可能になる感じですね。

サーバログインできる人でなければ実行できないことなので、気分的にある程度安心します。

SSHログバックアップ

自動ログバックアップを行いたいと考えたのですが、パスワード無しの鍵でログインして転送する形には抵抗がありました。

調べてみたところ、authorized_keysに公開鍵を記入する際の設定で、その鍵でできることを制限するという手段があるようでした。

具体的には、authorized_keysに

no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty,command="some commands" ssh-rsa AAAAB3NzaC1yc2EAAA...

などとして公開鍵を追加しておくと、その鍵でログインした直後にcommand=""の部分で設定したコマンドを実行して接続を終了する挙動となり

接続フォワードもできなくなるため、パスワード無しでも鍵の流出に関するリスクを最低限に留めることができるというわけです。

commandの実行結果は標準出力から受け取ることができるので、例えばcommand=""の部分にファイルの内容を表示する処理を設定していたとすれば

ssh -i .ssh/no_password_key user@xxx.xxx.xxx.xxx > /path/to/file

などとしてログインの結果をファイルに書き込むだけで、簡単にファイル転送が実現できます


まとめ

他にも大小さまざまな問題に行きあたりましたが、忘れてしまったor書ききれないのでここまでとします。

たった1つのサイトを公開するにしても問題というのは尽きないものだと実感させられました。

今は基本的な情報だけでなく、ちょっと突っ込んだ内容でも検索で解決していけるので嬉しいですね。手がかりを残してくれた先達に感謝することしきりです。

現状ではひとまずの見切りを付けて公開していますが、より堅牢で負荷に強いサーバとなるよう、随時チューニングを行なっていこうと考えています

最後

作ったWebサービスについて少し書きます

サイト名は「Radiosonde」

個人サイトや小規模な商業サイトなどプロモーションにあまりお金をかけられないサイトを主な対象とした、無料で出稿できる広告ネットワークサービスです。

既存サービスで近いのは「あわせて読みたい」や「zenback」、各社提供RSS相互リンクサービスなどになるでしょうか。

広告としての体裁がある分、それらより若干積極的な性質になるのではと考えています

現時点ではサービス本体のプロモーションに苦心するという本末転倒のものの状況でありますが、もしよろしければ見ていただけると嬉しいです。

2009-03-20

http://anond.hatelabo.jp/20090320070014

実作業が出来なくとも

それは貴重な存在だし、うちの会社にも欲しい。その分エンジニアコーディングや詳細設計に専念できる。

まあ、ただ、SIerと呼ばれる場所には実作業の知識がある奴が少なさすぎなんだがな。だからそういう仕事も回ってこなくて、知識もつかない。

基本情報は、そういう意味では悪くない知識分野をカバーしている。不足はあるけど、それほど無駄にはならない。

2008-12-14

[]歴史

前回のエントリに、思いのほかブックマークがついた。

せっかくなので、ここ2年ほどのさくらインターネットiDC移転を中心に、わかる範囲ではてなサーバ変遷の歴史をまとめてみようと思う。

さくらインターネットiDCへ順次移転
2007-01-29 mobile.hatena.ne.jp 追加
> 59.106.108.68:	mobile.hatena.ne.jp.
2007-02-03 f.hatena.ne.jp 移転
> 59.106.108.69:	f.hatena.ne.jp.
2007-02-16 rimo.tv 追加
> 59.106.108.70:	rimo.tv.
2007-03-14 不正侵入
2007-03-17 b.hatena.ne.jp 移転
移転
< 125.206.202.66:	mgw.hatena.ne.jp.
< 61.196.246.69:	b.hatena.ne.jp.
< 61.196.246.70:	b.hatena.ne.jp.
移転
> 59.106.108.71:	mgw.hatena.ne.jp.
> 59.106.108.72:	b.hatena.ne.jp.
2007-03-22 rimo.tv
2007-04-09 g.hatena.ne.jp 移転
移転
< 221.186.129.148:      g.hatena.ne.jp.
移転
> 59.106.108.73:        g.hatena.ne.jp.
2007-04-17 music.hatelabo.jp 終了
2007-04-21 anond.hatelabo.jp
2007-05-10 a.hatena.ne.jp
2007-05-22 rimo.tv
2007-05-22 XSS
2007-05-29 はてなロゴリニューアル
2007-06-05 r.hatena.ne.jp ring.hatena.ne.jp 移転
移転
< 125.206.202.82:       search.hatena.ne.jp.
< 221.186.129.147:      ring.hatena.ne.jp.
< 221.186.146.28:       a.hatena.ne.jp.
< 61.196.246.68:        r.hatena.ne.jp.
移転
> 221.186.129.147:      search.hatena.ne.jp.
> 59.106.108.74:        a.hatena.ne.jp.
> 59.106.108.75:        r.hatena.ne.jp.
> 59.106.108.76:        ring.hatena.ne.jp.
2007-06-26 d.hatena.ne.jp 移転
移転
< 125.206.202.83:       d.hatena.ne.jp.
< 221.186.129.146:      d.hatena.ne.jp.
< 221.186.146.29:       d.hatena.ne.jp.
< 61.196.246.67:        d.hatena.ne.jp.
移転
> 59.106.108.77:        d.hatena.ne.jp.
2007-07-05 ユーザー登録システム刷新
2007-07-11 s.hatena.ne.jp s.hatena.com m.hatena.ne.jp m.hatena.com 追加
> 59.106.108.97:        d.hatena.com.
> 59.106.108.97:        hatena.com.
> 59.106.108.97:        m.hatena.com.
> 59.106.108.97:        m.hatena.ne.jp.
> 59.106.108.97:        s.hatena.com.
> 59.106.108.97:        s.hatena.ne.jp.
2007-07-17 ポケットはてな ドコモ公式サイト
2007-07-19 XSS
2007-07-27 faviconリニューアル
2007-08-08 Rimoリニューアル
2007-08-16 ユーザー助け合い掲示板開設
2007-08-30 はてなキーワード
2007-09-13 お気に入りAPI公開
2007-09-21 はてな回線工事
2007-09-28 d2.hatena.ne.jp 追加
> 59.106.108.80:        d2.hatena.ne.jp.
2007-10-01 はてなサポート掲示板開設
2007-11-02 はてなスターOpenID受入
2007-11-08 OpenID提供
2007-11-13 d2.hatena.ne.jp

d2.hatena.ne.jpで新しいコメント構造の実験を開始しました - はてなダイアリー日記

2007-11-13 ☆の登録総数が1000万個を突破
2007-11-14 現代用語の基礎知識2008
2007-11-15 アンテナカウンター・検索を移転
移転
< 221.186.129.147:      counter.hatena.ne.jp.
< 221.186.129.147:      search.hatena.ne.jp.
移転
> 59.106.108.81:        counter.hatena.ne.jp.
> 59.106.108.82:        search.hatena.ne.jp.

アンテナフロントエンドはすでに移転(置換)してる模様

2007-11-30 XSS
2007-12-04 XSS
2007-12-05 XSS
2007-12-10 XSS
2007-12-13 w.hatena.ne.jp h.hatena.ne.jp 追加
> 59.106.108.78:	w.hatena.ne.jp.
> 59.106.108.84:	h.hatena.ne.jp.
> 59.106.108.84:	h.hatena.com.
> 59.106.108.98:	w.hatena.com.
2007-12-15 はてなハイク正式公開
2007-12-20 www.hatena.ne.jp q.hatena.ne.jp i.hatena.ne.jp graph.hatena.ne.jp map.hatena.ne.jp screenshot.hatena.ne.jp 移転
移転
< 221.186.146.27:	www.hatena.ne.jp.
< 61.196.246.68:	screenshot.hatena.ne.jp.
< 125.206.202.66:	map.hatena.ne.jp.
< 125.206.202.66:	i.hatena.ne.jp.
< 125.206.202.66:	graph.hatena.ne.jp.
< 125.206.202.66:	q.hatena.ne.jp.
移転
> 59.106.108.86:	www.hatena.ne.jp.
> 59.106.108.87:	screenshot.hatena.ne.jp.
> 59.106.108.88:	map.hatena.ne.jp.
> 59.106.108.89:	i.hatena.ne.jp.
> 59.106.108.92:	graph.hatena.ne.jp.
> 59.106.108.99:	q.hatena.ne.jp.
2007-12-21 d2.hatena.ne.jp
2008-01-04 i.hatena.ne.jp 移転
2008-01-07 auth.hatena.ne.jp 移転
移転
< ???.???.???.???:	auth.hatena.ne.jp.
移転
> 59.106.108.90:	auth.hatena.ne.jp.
2008-01-09 hatelabo.jp 移転

長いので省略

2008-01-18 d2.hatena.ne.jp
2008-01-24 なぞなぞ認証
2008-01-25 serif.hatelabo.jp 移転
2008-01-25 サーバ移転完了
2008-01-25 d2.hatena.ne.jp
2008-01-26 anond.hatelabo.jp
2008-01-28 rokuro.hatelabo.jp 追加
> 59.106.108.93:	rokuro.hatelabo.jp.
2008-01-31 h.hatena.com
2008-02-07 認証セット
2008-02-14 はてな本移転
2008-02-19 認証セット
2008-02-28 f.hatena.ne.jp
2008-03-25 f.hatena.ne.jp
2008-03-31 map.hatena.ne.jp
2008-04-24 f.hatena.ne.jp
2008-04-25 ring.hatena.ne.jp
2008-05-03 XSS
2008-05-22 はてなクラブ開始
2008-05-29 f.hatena.ne.jp
2008-06-05 f.hatena.ne.jp
2008-06-10 w.hatena.ne.jp
2008-07-15 b.hatena.ne.jp
2008-08-26 ネットワーク基幹ルータの入れ替え
2008-08-28 d.hatena.ne.jp
2008-09-01 rimo.tv 終了
2008-09-01 k.hatena.ne.jp 追加
> 59.106.108.102:	k.hatena.ne.jp.
2008-10-30 f.hatena.ne.jp
2008-11-07 はてなブックマークベータテスト開始
> 59.106.108.103:	favicon.hatena.ne.jp.
> 59.106.108.105:	img.b.hatena.ne.jp.
> 59.106.108.106:	bbeta.hatena.ne.jp.
2008-11-25 はてなブックマークリリース
2008-11-26 ring.hatena.ne.jp
2008-12-04 news.hatelabo.jp counting.hatelabo.jp bottle.hatelabo.jp 追加
> 59.106.108.93:	bottle.hatelabo.jp.
> 59.106.108.93:	counting.hatelabo.jp.
> 59.106.108.93:	news.hatelabo.jp.
余談 はてなサーバの実態あれこれ

2007-05-09

http://anond.hatelabo.jp/20070509092511

その為のアメリカはてな.incなんじゃないの?

日本の場合は社長会社の連帯保証になってるケースが多いので

トップの身柄を確保を最優先するけど主とする住居がアメリカじゃそう簡単に手を出せない。

村上を確保したとき並みのやりかたをしないと…。

租税条約があるから一番ひっぱりやすい税務関係だって厳しくなる。

元々イニシャルコストがかからない事業ばっかりしているので恐らく借り入れもあまりない。

はてなをひっぱろうとしたら相当苦労すると思うよ。

jkondoが去年の7/15出立だから、ボーダーの183日は充分滞在しているでしょ。

少なくとも租税条約は結ばれた国同士で課税の重複はないからjkon自体は米国での納付となる。

国際連結決算がどうなってるかしらないけど、はてなの収益なんて殆どがGoogleアドセンスなんだから米国内に法人を持っていれば付け替えなんていくらでもできね? シリコンバレー以外にもタクスフリーなところに会社もってるかもしらん。

シリコンバレー法人税ってどうなってるんだろ?ベンチャー多いってことは優遇されてるのかな??)

はてなサーバーアメリカに移ってたりしてな。

さくらは負荷分散のための参照用レプリケーションでコアのデータベースアメリカにありますとか。

米国プライマリですとか言い訳できるぐらいの環境を整えてれば言い訳は立ちそう。

日本で受動的に天下りとか献金をすることにより政治活動をするぐらなら、

アメリコさんでわいがjkondoやー!ロビー活動やー!ピザや!ピザをもってこい!!

とやったほうがベンチャーにはいいかもしれない。

というかはてな法律関係は相当詳しいやつが既にいると思う。

昔しからだけど、いろいろ匂うねん。

2007-03-25

anond:20070324225204

はてブでもたまに似たような状態になるね。

DBレプリケーションしているのか、更新情報アプリ/モジュール上でキャッシュしてまとめ書きしてるのかしらないけど。

2006-12-16

はてブの「追加して確認」ボタン

中身が更新されていないことがあるんだけど。

DBレプリケーションでもやってるのかな?

 
ログイン ユーザー登録
ようこそ ゲスト さん