5日目は、インフラ&コアテク本部の@nekoruriが担当します。私たちが所属するインフラ&コアテク本部は、「(^q^)くおえうえーーーるえうおおおwwwwwwwwwwwwwww」でお馴染みアニメ放映中のガールフレンド(仮)やアメブロを初めとするAmeba、755などグループ会社に対して、最適化されたサービスインフラとその運用ノウハウを提供する組織です。自社開発のプライベートクラウドの開発・運用だけでなく、パブリッククラウドやCDNなどの外部サービスの活用支援や、サービスに関するセキュリティプロセスなど、「サービスを動かす基盤」全体の向上に責任を負っています。Storage)と呼ばれるオブジェクトストレージについて紹介します。Storage以前エンジニアブログで紹介した画像配信基盤とは別に、変換など画像に特化した機能がない代わりに汎用に使えるAOSという汎用データストアを運用しています。スマホ専用電子コミックサイト「読書のお時間です」や「アメーバピグ」などで使われているほか、自社のネットワーク内にあり、通信費を掛けずに大量に高速の転送が可能という利点を活かし、各サービスのバックアップデータなども保管しています。比較すれば、某氷河系ストレージほど安くは無いが柔軟に利用でき、某低冗長化ストレージよりは安価で気楽に利用できる、という感じの位置付けを目指しています。こんな感じの目的を実現するため、クラウド基盤OSSのOpenStackに含まれるSwiftをベースに、キャッシュや管理機能を追加したものがAOSです。AOSの全体像がこちらです。Swiftを中心に、キャッシュとパス変換のためのVarnishを前段に置き、それらを管理する管理画面を自作しています。独自の認証基盤へ繋ぎ込むため、Keystone等は利用せず、管理画面からswauthへの同期を行っています。VarnishマジVarnish静的なファイルの配信と言えばキャッシュです。あらゆる段階でキャッシュをどれだけ活かすことができるかに、サービスの品質やコストが直結します。AOSではVarnishによるキャッシュを標準で提供することで、そういった要求に対応しています。データストアの人柱として有名な弊社ですので、もちろんVarnishのバックエンドストレージとしてもpersistentを利用しています。他のmallocやfileではvarnishdを再起動するとキャッシュデータが消えてしまうのですが、persistentであれば永続化されているためカジュアルにrestartできます。いいつつ、persistentはやむを得ない理由が無ければ使うなという状況になっているため、今後はどうしようかなというところです。特徴的な使い方としては、AOSへはいくつかのホスト名を付与していて、ホスト名ごとにVarnishのキャッシュポリシーを変更しています。上位にAkamai等のCDNを挟む場合は、中間層でのキャッシュがトラブルの元となる可能性があるため、一切キャッシュをしないホスト名を用意しています。簡単なVCLでこのような柔軟な対応ができるのもVarnishならではですね!認証にswauthを利用しているため、Swiftそのままだと、URLにhttp://example.jp/AUTH_12345678-1234-1234-1234-1234567890ab/file.jpgのような「AUTH_」で始まるアカウントの識別子が含まれてしまい、ちょっと格好悪いです。そこで、Varnishに変換ルールを仕込み、管理画面からその変換ルールを設定できるようにしています。キャッシュのパージも管理画面から実施できます。このように、開発者がインフラエンジニアの手に頼らず自力で設定できる環境を整備していくのも、インフラ&コアテク本部のミッションの一つです。ちなみに、varnishには「うわべだけ取り繕う」「ごまかす」という意味があるそうです。細かすぎて伝わらないSwiftのTIPSまさかのGREEさんとのネタ被りですが、オブジェクトストレージの根幹となっているのがSwiftです。国内だとGMOインターネットのこのはちゃんが採用しているのでご存知の方が多いと思います。Swiftの紹介とか書いても、SwiftStackのドキュメントより分かりやすいものができるわけもないので、AOSの担当になってから今までに得た細かいTIPSを書いていきます。ゾーン追加とレプリカ数Swiftはデータの冗長性を確保するため、「極力遠くに同じデータ(標準では3つのレプリカ)を保存する」という仕組みになっています。この「遠さ」を表現するために、以下のような階層が用意されています。(データの保存単位)全てのデータは、Partitionという単位でまとめられて、それがどこかのRegion、Zone、Node、Diskに分散してばらまかれる事になります。この分散先を決めるときに先ほどの「極力遠くに」というポリシーが前提となるわけです。1サーバ1ディスクだけのテストサーバであればその1ディスクの那珂に全部入りますし、たくさんのリージョンに別れた広域分散環境であれば、良い感じに分散してくれるというわけです。Zoneとして構築しました。その後、順調に利用量が増えて1ラック分サーバを追加することになりました。サーバ追加するだけで簡単にキャパシティも増える夢のストレージですよさすがですね!ただ、いくら追加すれば良いとはいえ、初の大規模拡張なので、何かあってもすぐ切り戻せるように少しずつ追加していきたいところです。mount生やしまくりで数だけ合わせて1GBのディスクをなんと合計200本以上も作りました。Zoneをまたいで分散しろというプレッシャーが強すぎて、追加した1台のサーバに3つめのレプリカが集中してしまうのです。Swiftには、どのサーバにどれだけのデータを割り振るかを「Weight」として指定することができるのですが、Zoneを跨げという力の前には無力で、たとえweightを他のサーバの1/100にしていても同じ結果でした。いうわけで、最初のキャパシティプランニング段階でZone数はレプリカ数に合わせて設計しておき、Zone内でのサーバ追加で対応できるようにするのが良いです。いうコマンドを使うと、全てのサーバ・全てのディスクごとに、利用率を比較することができます。63.8695950433%===============================================================================サーバを追加すると、0%のところに「*」が増えて、データ同期が進むにつれてじわじわ他の利用率に近寄っていきます。そこで、この出力をみんなだいすきGrowthForecastに流し込んであげればさらっと可視化できます。recon_growthforecast.shとして置いておきますので、興味がある方はお試しください。あと、当然ながら、でっかいストレージだとデータ同期もでっかい時間が掛かります。100TB/1Gbps=約9.3日、という計算式を置いておきます。swauthのパスワードを調べるswauthは、OpenStack標準の認証コンポーネントであるKeystoneを使わないときに用いるSwift独自の認証機構です。swauthはSwift内部のミドルウェアとして組み込まれ、認証情報をSwift自身に保存します。驚きのplaintextで。そのため、swauthのパスワードを後から取得することができます。swauthが認証に関する情報を保存するため、super_admin_keyというマスターパスワードを使います。このsuper_admin_keyというさも強そうなパスワードは、プロキシサーバの設定ファイルに書かれています。"plaintext:USERPASSWD"}これでパスワードを忘れても大丈夫ですね!コンテナ内のファイル数という話題で書こうとしていたら、GREEさんとネタが被ったので省略します。物理配置を調べるどのデータをどのノードのどのディスクに保存するかは、リングと呼ばれるファイルで定義されています。swift-get-nodesというコマンドにこのリングファイルを食わせてあげることで、どこに物理的に配置できるかを知ることができます。手順的には二段階で、まず対象のアカウントを調べます。API(curl)でコンテナの情報を取ったり、対象サーバに接続してディレクトリをlsするワンライナーがどかどか表示されるところです。DBがどれぐらいのサイズに太っちゃったか知りたくなったときも、表示されれたssh行を実行すれば、すぐに該当ディレクトリをlsしてDBサイズを診ることができるわけです。ソースコードSwiftの一番良いところは、Pythonで書かれていて、ソースコードにもすぐにアクセスができるところです。ソースコードも良い意味でそれほど大きくないため、LL言語に馴染みのある人であれば、ちょっとした動きに違和感があり調査が必要になっても追いかけることがで来ます。Grizzlyのswift-ring-builderコマンドにはIPv6アドレスを受け取れない不具合があるのですが、ちょっと検索すれば正規表現を直すパッチが転がっていたりしますし、作業用サーバだけ手パッチ当てて動作確認みたいなこともすぐに可能です。ここまでカジュアルに深いところまで触りやすいデータストアはSwiftぐらいでは無いでしょうか。「Swift」どこかのアップルとか言うスマホの会社がiOS(IOS)に続いてど派手な名前被りをしてくれたせいで、「Swift」という語句のググラビビリティが大変下がってしまいました。Swift」で検索しましょう。まとめSwiftは、OpenStackのコンポーネント群のなかでも、Rackspaceが商用サービスで使っていたものをベースとしているだけあって非常に枯れています。HTTP(REST)ベースということで内部のトラブルシュートもしやすいです。うまく他のネットワーク環境との兼ね合いや機器構成を練らないと、パブリッククラウドのオブジェクトストレージとコストだけで闘うのは厳しいですが、うまくユースケースにはまればとても便利な基盤になるので、どうぞご利用ください。再受賞(2019)Slack情報収集のためのチートシートデザインテーマ変えてみましたもっと見る月別アーカイブ検索はてなブログをはじめよう!nekoruriさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。