ZooKeeperの分散構成については、この記事を読んでください

[[430218]]

この記事はWeChatの公開アカウント「Mu Xiaonong」から転載したもので、著者はMu Xiaonongです。この記事を転載する場合は、穆小農の公式アカウントまでご連絡ください。

ZooKeeperの起源

追記：これは重要ではありません。興味がない場合は、以下をご覧ください。

出典: Paxos から ZooKeeper へ

ZooKeeper は Yahoo Research の研究チームから生まれました。当時、研究者たちは、Yahoo 内の多くの大規模システムは基本的に分散調整のために同様のシステムに依存する必要があるが、これらのシステムには分散単一ポイントの問題が頻繁にあることを発見しました。そこで Yahoo の開発者は、開発者がビジネスロジックの処理に集中できるように、単一点の問題のない汎用的な分散調整フレームワークの開発に取り組みました。プロジェクト名「ZooKeeper」について。物語もあります。プロジェクトの開始当初、多くの社内プロジェクトが動物にちなんで命名されていたこと (たとえば、Pig プロジェクト) を考慮して、Yahoo のエンジニアはこのプロジェクトにも動物にちなんで名前を付けたいと考えていました。当時、研究所の主任科学者であるラグ・ラマクリシュナン氏は「この状態が続けば、この場所は動物園になってしまうだろう」と冗談を言った。こう言うとすぐに、みんながそれを Zookeeper と呼ぶべきだと言いました。動物にちなんで名付けられた分散コンポーネントを組み合わせると、分散システムは大きな動物園のように見え、分散環境を調整するために ZooKeeper が使用されるため、ZooKeeper という名前が生まれました。

分散構成センター

前回は、ZooKeeper クラスターの構成とインストールについて説明しました。 ZooKeeper クラスターは主に分散調整に役立ちます。現在、分散構成を実装するために ZK を使用しています。 ZooKeeper クラスターの構成については、前回の記事「ZooKeeper クラスターの展開について」を参照してください。

分散構成センターがなぜ必要なのでしょうか?

当初、多くの企業のサーバーは単一のノードで構成されていましたが、ビジネスの発展に伴い、単一ノードのサービスではビジネスの急速な発展に対応できなくなります。その後、分散とクラスタリングの概念が登場しました。現在ではマイクロサービスが形成され、技術的な改善によりビジネスのニーズをより適切に満たすことができます。

さまざまなサーバーに分散された多数のオンラインマイクロサービスがあるとします。マイクロサービスの 1 つは、goods-service と呼ばれます。 goods-service の IP アドレスを変更する必要があるが、goods-service は他の多くのプログラムにサービスを提供しているため、統一された構成がない場合、goods-service に適用されている各アプリケーションで対応する IP アドレスの変更を行う必要があり、非常に面倒です。

この問題は、分散構成に ZooKeeper を使用すると解決できます。

レジストリの比較

サービスガバナンスだけを考慮すると、Eureka の方が適しています。 Eureka はより純粋な登録センターです。 Eureka とは異なり、Apache ZooKeeper は設計時に CP 原則に従います。いつでも ZooKeeper へのアクセス要求により一貫したデータ結果が得られます。同時に、システムはネットワークのセグメンテーションに対して耐障害性を備えています。今日は、ZooKeeper 登録検出についてお話します。

構成センターの中核

低レイテンシ: 構成変更(作成/更新/削除)後、最新の構成をできるだけ早く他のノードに同期できます。

高可用性: 構成センターは外部に安定したサービスを提供できる

ZooKeeper の Watcher メカニズムを通じて低レイテンシを実現できます (Watcher メカニズムについては後で説明します)。ノードは構成情報を保存することに同意します。各クライアントは、このノードの NodeDataChanged イベントをリッスンします。構成が変更されると、最新の構成がこのノードに更新されます。誰が更新するかは関係なく、どのノードでも更新できます。このノードが NodeDataChanged イベントをトリガーすると、このノードをリッスンしているすべてのクライアントに通知して、このノードの最新情報を取得します。ウォッチャーは 1 回限りなので、最新情報を取得するときにリスニングイベントを設定する必要があります。ほとんどのクエリ情報はアトミックであるため、ZooKeeper の getData もアトミック操作であり、取得する情報が最新のものであることを保証できます。

高可用性を実現するには、まず ZooKeeper を導入するためにマルチクラスター操作を確保する必要があり、コードレベルで行う作業はそれほど多くありません。

時計のメカニズム

Watch は、ノードに対する ZooKeeper の 1 回限りのオブザーバーメカニズムです。上記の「低レイテンシ」で述べたように、一度トリガーされると無効になり、手動で再作成する必要があります。

Watch によって監視されるデータが変更されると、Watch を設定したクライアント (API の Watcher) に通知されます。 Watcher メカニズムは Znode ノードの変更を監視するため、対応するイベントタイプとステータスタイプが存在します。コード内のスイッチは監視に使用されます。クライアントは複数のノードに接続でき、Znode ノードが変更される限り、プロセス (WatchedEventevent) が実行されます。

次の図に示すように:

上の図から、ZooKeeper では、Watch がクライアントポーリングではなくプッシュメカニズムを使用していることがわかります。一部のミドルウェアでは、KafKa などプルモードが使用されます。

ウォッチには、イベントタイプとステータスタイプの 2 つの監視モードがあります。

イベントタイプ: Znode ノードの関連付け (主にノード操作用)

ノードを作成する: EventType.NodeCreated
ノードデータの変更: EventType.NodeDataChanged
現在のノードの子ノードが変更されました: EventType.NodeChildrenChanged
ノードの削除: EventType.NodeDeleted

ステータスタイプ: クライアントの関連付け。主にZooKeeperクラスタとアプリケーションサービス間のステータス変更用

接続されていません: KeeperState.Disconnected
接続済み: KeeperState.SyncConnected
認証に失敗しました: KeeperState.AuthFailed
有効期限: KeeperState.Expired
クライアントは読み取り専用サーバーに接続されています: KeeperState.ConnectedReadOnly

時計の特徴

ワンタイムトリガー: ZooKeeper の Watcher イベントの場合、これはワンタイムトリガーです。ウォッチによって監視されているデータが変更されると、現在のウォッチを設定したクライアント (対応するウォッチャー) に通知されます。 ZooKeeper の監視は 1 回限りなので、トリガーごとに監視を設定する必要があります。

クライアントのシリアル実行: クライアント Watcher コールバックプロセスはシリアル同期プロセスであり、順次実行を保証できます。

軽量: WatchedEvent は、ZooKeeper の Watcher 通知メカニズム全体の最小の通知単位であり、3 つの部分 (通知ステータス、イベントタイプ、ノードパス) で構成されます。ウォッチャー通知は、イベントが発生したことをクライアントに伝えるだけで、具体的な内容は伝えません。それを取得するには、クライアントが率先して行動する必要があります。たとえば、WatchedEvent.NodeDataChanged 情報の変更をリッスンすると、このノードのデータが変更されたことのみが通知され、最新の値がすぐに取得されるはずです。

クライアントによって設定された各ウォッチポイントはセッションに関連付けられており、セッションの有効期限が切れると、保留中のウォッチポイントは削除されます。ただし、異なるサーバーへの接続間で監視を維持することは可能です。たとえば、ZooKeeper クライアントが ZooKeeper サーバーから切断し、セット内の別のサーバーに接続すると、クライアントはトリガーされていないウォッチのリストを送信します。ウォッチを登録すると、サーバーはウォッチが以前に登録されてから監視対象の znode が変更されたかどうかを確認します。 znode が変更された場合は、監視イベントがクライアントに送信され、それ以外の場合は監視が新しいサーバーに登録されます。このメカニズムにより、基礎となる接続自体ではなく、論理層のセッションを考慮できるようになります。

クライアント登録

ZooKeeper に登録する場合、ZooKeeper サーバーに登録を要求します。サーバーはリクエストに対する応答を返します。成功か失敗かに関係なく、応答結果が返されます。応答が成功すると、ZooKeeper サーバーは Watcher オブジェクトをクライアントの WatchManager 管理に配置し、クライアントに応答を返します。

サーバー登録

FinalRequestProcessor.ProcessRequest() は、現在のリクエストがウォッチャーを登録する必要があるかどうかを判断します。

ZooKeeper は、現在のクライアントが Watcher に登録する必要があると判断した場合、現在の ServerCnxn オブジェクトとデータパスを getData メソッドに渡します。 ServerCnxn は、ZooKeeper クライアントとサーバー間の接続インターフェースであり、クライアントとサーバー間の接続を表します。 ServerCnxn は Watcher プロセスインターフェイスを実装しているため、Watcher オブジェクトと見なすことができます。

ウォッチャーマネージャー

WatcherManager は、ZK サーバー Watcher のマネージャーであり、WatchTable と Watch2Paths の 2 つのストレージ構造に分かれています。これら 2 つは異なるストレージ構造です。 1) WatchTable: データノードパスの粒度からWatcherを管理します 2) Watch2Paths: Watcherの粒度から時間からデータノードを制御します

サーバー側では、dataWatches (データ変更監視) と childWatches (子ノード変更監視) という 2 つの WatchManager が DataTree でホストされます。

ウォッチャートリガーロジック

1) WatchedEvent をカプセル化: (KeeperState (通知状態)、EventType (イベント種別)、Path (ノードパス)) を WatchedEvent オブジェクトにカプセル化します。 2) Watcher をクエリ: パスに応じて対応する Watcher を取得します。存在する場合は、データを取得してWatcherManager（WatchTable/Watch2Paths）から削除します。3）Processメソッドを呼び出してWatcherをトリガーします。

4. クライアントコールバックウォッチャー

1) 逆シリアル化: バイトストリームを WatcherEvent オブジェクトに変換します。2) chrootPath を処理します。クライアントが chrootPath 属性を設定する場合、サーバーから送信された完全なノードパスを chrootPath で処理して、クライアントの相対ノードパスを生成する必要があります。たとえば、(/mxn/app/love は、chrootPath 処理後、/love になります) 3) WatchedEvent を復元: WatcherEvent を WatchedEvent に変換します 4) ウォッチャーをコールバック: WatcherEvent オブジェクトを EventThread スレッドに渡し、次のポーリングサイクルでウォッチャーコールバックを実行します

EventThreadはイベント通知を処理します

1) SendThread はサーバーから通知イベントを受信すると、EventThread.queueEvent メソッドを呼び出してイベントを EventThread スレッドに渡します。 2) queueEvent メソッドは、まず通知イベントに基づいて ZKWatchManager から関連するすべてのウォッチャーを取得します。クライアントはイベントタイプ EventType を識別した後、対応する Watcher を対応する Watcher ストレージ (つまり、3 つの登録方法 (dataWatches、existWatcher、または childWatcher)) から削除します。 3) 関連するすべてのウォッチャーを取得すると、それらは waitingEvents キューに配置されます。

コードの実装

次に、コードを使用してZooKeeper構成を実装する方法を説明します。

まずZK jarをインポートする必要があります

<依存関係>
      <グループ ID>org.apache.zookeeper</グループ ID>
      <artifactId>動物園の飼育係</artifactId>
      <バージョン>3.6.3</バージョン>
    </依存関係>

構成クラス

分散構成を行うので、まずサービスのアドレスを同期するために使用される構成をシミュレートする必要があります。

 /**
 * @プログラム: mxnzookeeper
 * @クラス名 MyConf
 * @description: 構成クラス
 * @著者: muxiaonong
 * @作成日: 2021-10-19 22:18
 * @バージョン 1.0
 **/
パブリッククラスMyConfig{ 
 
    プライベート文字列conf; 
 
パブリック文字列 getConf() {
 confを返します。
    } 
 
パブリックvoid setConf(String conf) {
        conf を次のように変更します。
    } 
 
 }

ウォッチャー

ZooKeeper を作成するときは、監視するための Watcher が必要です。後で Znode ノードを操作するときには Watcher も使用する必要がありますが、これら 2 つのクラスの機能は異なるため、次に示すように独自のウォッチャークラスを定義する必要があります。

 org.apache.zookeeper.WatchedEvent をインポートします。
 org.apache.zookeeper.Watcher をインポートします。 
 
 java.util.concurrent.CountDownLatch をインポートします。 
 
 /**
 * @プログラム: mxnzookeeper
 * @ClassName デフォルトウォッチ
 * @説明：
 * @著者: muxiaonong
 * @作成日: 2021-10-19 22:02
 * @バージョン 1.0
 **/
パブリッククラスDefaultWatchはWatcherを実装します{ 
 
    カウントダウンラッチ cc; 
     
パブリックvoid setCc(CountDownLatch cc) {
        this.cc = cc;
    } 
 
    @オーバーライド
パブリックvoid プロセス(WatchedEvent イベント) {
        システム。出力.println(event.toString()); 
 
        スイッチ（イベント.getState()）{
ケース不明:
                壊す;
切断された場合:
                壊す;
 NoSyncConnectedの場合:
                壊す;
 SyncConnectedの場合:
                システム。 out .println( "接続に成功しました..." );
                //接続が成功したらcountDownを実行し、zkオブジェクトを使用できます
                cc.countDown();
                壊す;
 AuthFailedの場合:
                壊す;
 ConnectedReadOnlyの場合:
                壊す;
 SaslAuthenticatedの場合:
                壊す;
期限切れの場合:
                壊す;
事件は解決しました:
                壊す;
        } 
 
    }
 }

操作は非同期で実行されるため、ZooKeeper オブジェクトを作成した後、ブロッキング操作を実行しないと、接続が完了する前に後続の操作が実行される可能性があります。したがって、ここではブロック操作に CountDownLatch を使用します。監視接続が成功すると、countDown が解放され、後続の ZK アクションが実行されます。

ZooKeeper に正常に接続したら、ノードが存在するかどうかを判断するために exists を使用する必要があります。存在する場合は、getData 操作を実行します。ここでは、exists と getData の両方にコールバックが必要なため、WatchCallBack を作成します。そのため、Watcher の実装に加えて、ノードステータス (AsyncCallback.StatCallback) とデータ監視 (AsyncCallback.DataCallback) も実装する必要があります。

 org.apache.zookeeper.AsyncCallback をインポートします。
 org.apache.zookeeper.WatchedEvent をインポートします。
 org.apache.zookeeper.Watcher をインポートします。
 org.apache.zookeeper.ZooKeeper をインポートします。
 org.apache.zookeeper.data.Stat をインポートします。 
 
 java.util.concurrent.CountDownLatch をインポートします。 
 
 /**
 * @プログラム: mxnzookeeper
 * @ClassName ウォッチコールバック
 * @説明：
 * @著者: muxiaonong
 * @作成日: 2021-10-19 22:13
 * @バージョン 1.0
 **/
パブリッククラス WatchCallBack は Watcher、AsyncCallback.StatCallback、AsyncCallback.DataCallback を実装します { 
 
    ZooKeeper zk ;
    MyConfig conf;
    カウントダウンラッチcc = 新しいカウントダウンラッチ(1); 
 
パブリックMyConfig getConf() {
 confを返します。
    } 
 
パブリックvoid setConf(MyConfig conf) {
        conf を次のように変更します。
    } 
 
パブリックZooKeeper getZk() {
 zkを返します。
    } 
 
パブリックvoid setZk(ZooKeeper zk) {
        this.zk = zk;
    } 
 
 
パブリックvoid aWait(){
        //非同期実装バージョンが存在する
        zk.exists(ZKConstants.ZK_NODE、this、this 、 「existsウォッチ」 );
        試す {
            cc.await();
        } キャッチ (InterruptedException e) {
            e.printStackTrace();
        }
    } 
 
    /** @著者 mxn
     * @Description //TODO このコールバックはノードのステータスを取得するために使用されます
     * @日付2021/10/20 21:24
     * @param rc 呼び出しによって返されるコードまたは結果
     * @param path 非同期呼び出しに渡されるパス
     * @param ctx 非同期呼び出しに渡されるコンテキスト オブジェクト
     * @param statはパス上のノードのStatオブジェクトを指定します
     * @戻る  
     **/
    @オーバーライド
パブリックvoid processResult( int rc, String path, Object ctx, Stat stat) {
        （統計値!= null ）の場合{
            //getData の非同期実装バージョン
            zk.getData(ZKConstants.ZK_NODE、this、this、 「ステータス」 );
        }
    } 
 
 
    /** @著者 mxn
     * @Description //TODO このコールバックはノードのデータと統計を取得するために使用されます
     * @日付2021/10/20 21:23
     * @param rc 呼び出しによって返されるコードまたは結果
     * @param path 非同期呼び出しに渡されるパス
     * @param ctx 非同期呼び出しに渡されるコンテキスト オブジェクト
     * @param data ノードデータ
     * @param statはノードのStatオブジェクトを指定します
     * @戻る 
     **/
    @オーバーライド
パブリックvoid processResult( int rc, String path, Object ctx, byte[] data, Stat stat) {
        データ!= nullの場合{
            文字列 s = 新しい文字列(データ);
            conf.setConf(s);
            cc.countDown();
        }
    } 
 
    /** @著者 mxn
     * @Description //TODO Watcher インターフェースの実装。
     * Watcher インターフェイスは、イベント ハンドラー クラスが実装する必要があるパブリック インターフェイスを指定します。
     * ZooKeeper クライアントは、接続している ZooKeeper サーバーからさまざまなイベントを取得します。
     * このクライアントを使用するアプリケーションは、コールバック オブジェクトをクライアントに登録することによってこれらのイベントを処理します。
     * コールバック オブジェクトは、Monitor インターフェイスを実装するクラスのインスタンスである必要があります。
     * @日付2021/10/20 21:24
     * @Param watchingEvent WatchedEvent は、ウォッチャーが応答できた ZooKeeper の変更を表します。
     * WatchedEventには何が起こったかが含まれます。
     * ZooKeeper の現在の状態と、イベントに関係する znode へのパス。
     * @戻る  
     **/
    @オーバーライド
パブリックvoid プロセス(WatchedEvent イベント) {
        スイッチ（イベント.getType()）{
ケースなし:
                壊す;
 NodeCreatedの場合:
                //ノードが作成されたら、ノードを取得します
                //getData は StatCallback のコールバック processResult をトリガーします
                zk.getData(ZKConstants.ZK_NODE、this、this、 "sdfs" );
                壊す;
 NodeDeletedの場合:
                //ノードの削除
                conf.setConf( "" );
                //CountDownLatchを再度開く
                cc = 新しいCountDownLatch(1);
                壊す;
 NodeDataChangedの場合:
                //ノードデータが変更されました
                //DataCallbackのコールバックをトリガーする
                zk.getData(ZKConstants.ZK_NODE、this、this、 "sdfs" );
                壊す;
                //子ノードが変更されたとき
NodeChildrenChangedの場合:
                壊す;
        } 
 
 
    }
 }

すべての準備が整ったら、テストケースを記述できます。

ZKユーティリティ

org.apache.zookeeper.ZooKeeper をインポートします。 
 
 java.util.concurrent.CountDownLatch をインポートします。 
 
 /**
 * @プログラム: mxnzookeeper
 * @クラス名 ZKUtils
 * @説明：
 * @著者: muxiaonong
 * @作成日: 2021-10-19 21:59
 * @バージョン 1.0
 **/
パブリッククラスZKUtils { 
 
    プライベート静的ZooKeeper zk; 
 
    //192.168.5.130:2181/mxn 末尾の/mxnは、クライアントがzkクラスタへの接続を正常に確立した場合、
    // クライアントのデフォルトのルート パスは /mxn になります。 /mxnが含まれていない場合、デフォルトのルートパスは/です。
    //もちろん、/mxnノードがZK上に存在することを確認する必要があります
    プライベート静的文字列アドレス = "192.18.5.129:2181,192.168.5.130:2181,192.168.5.130:2181/mxn" ; 
 
    プライベート静的DefaultWatch ウォッチ = 新しい DefaultWatch(); 
 
    プライベート静的CountDownLatch init = new CountDownLatch(1); 
 
公共 静的ZooKeeper getZK(){ 
 
        試す {
            //非同期なので、後続の操作を実行する前に、zk クラスターが接続されるまで待機する必要があります。
            zk = 新しい ZooKeeper(アドレス、1000、ウォッチ);
            ウォッチ.setCc(init);
            init.await(); 
 
        } キャッチ (例外 e) {
            e.printStackTrace();
        } 
 
 zkを返します。
    } 
 
 }

テストクラス:

 org.apache.zookeeper.ZooKeeper をインポートします。
 org.junit.Before をインポートします。
 org.junit.Test をインポートします。 
 
 /**
 * @プログラム: mxnzookeeper
 * @クラス名テスト構成
 * @説明：
 * @著者: muxiaonong
 * @作成日: 2021-10-19 22:04
 * @バージョン 1.0
 **/
パブリッククラスTestConfig{ 
 
    ZooKeeper zk; 
 
    @前に
パブリックvoidconn(){
        ZKUtils の getZK() メソッドは、次のコードで使用できます。
    } 
 
    /** @著者 mxn
     * @Description //TODO ZKを閉じる
     * @日付2021/10/20 21:16
     * @パラメータ
     * @戻る 
     **/
パブリックボイドクローズ（）{
        試す {
            zk.close ();
        }(例外 e) をキャッチ{
            e.printStackTrace();
        }
    } 
 
    @テスト
パブリックvoid getConf(){
        WatchCallBack watchCallBack = 新しい WatchCallBack();
        watchCallBack.setZk(zk);
        新しいMyConfig()を作成します。
        watchCallBack.setConf(myConfig); 
 
        //ブロッキング待機
        watchCallBack.aWait(); 
 
 
        while( true ){ 
 
            if(myConfig.getConf().equals( "" )){
                システム。 out .println( "zk ノードが失われました......" );
                コールバックを待機します。
            }それ以外{
                システム。出力.println(myConfig.getConf()); 
 
            }
 //
            試す {
                //500ミリ秒ごとに印刷
                スレッド.sleep(500);
            } キャッチ (InterruptedException e) {
                e.printStackTrace();
            }
        } 
 
 
    }

テストの実行

まず、IP に接続するときに /mxn ディレクトリ構造を追加したので、サーバーの初期状態でこのノードが存在する必要があることを知っておく必要があります。

クラスターの初期状態:

 [zk: localhost:2181(接続済み) 7] ls /
 [mxn、動物園の飼育員]

プログラムを開始して見てみましょう

接続に成功しました

ZooKeeper /mxnも空になりました

[zk: localhost:2181(接続済み) 9] ls /mxn
 []
 [zk: localhost:2181(接続済み) 10]

それでは、/mxn/myZNodeノードデータを作成しましょう

[zk: localhost:2181(接続済み) 10] /mxn/myZNode "muxiaonong666"を作成します 
 /mxn/myZNode を作成しました

ご覧のとおり、作成が完了すると、プログラムはすぐに応答し、私が設定した値、muxiaonong666を出力します。

このとき、/mxn/myZNodeの値をmuxiaonong6969に設定します。

スナップ！本当に早いですね！！！値が瞬時に変化することがわかります

このとき、/mxn/myZNode ノードを削除するとどうなるでしょうか?以前にも時計について書いたことがあります。 Znode が削除されると、ウォッチとコールバックが実行されます。

 NodeDeletedの場合:
                //ノードの削除
                conf.setConf( "" );
                //CountDownLatchを再度開く
                cc = 新しいCountDownLatch(1);
                壊す; 
 
 
 
 if(myConfig.getConf().equals( "" )){
              システム。 out .println( "zk ノードが失われました......" );
                ////この時点で、ノードが再作成されるまでブロックして待機する必要があります
                watchCallBack.aWait();
  }

/mxn/myZNodeノードを削除します

/mxn/myZNodeを削除します

最初はデータがまだ印刷されていることがわかりますが、後でデータが失われるというメッセージが表示されます。

ただし、現時点ではクライアントは閉鎖されておらず、データの更新を待機中です。この時点で /mxn/myZNode ノードを再作成すると、プログラムは異常な出力を続けます。

 /mxn/myZNode "muxiaonong666"を作成します。

プログラムは正常に実行され、zk 構成の最新データを正常に取得します。この時点で、ZooKeeper の分散構成センター機能は基本的に実現されます。

ここではgetDataでテストしましたが、実際のプロジェクトでは、より多くの子ノード操作getChildrenを使用する可能性があります。

要約する

これで、ZooKeeper の分散構成、登録、検出に関する記事は終了です。ご質問がございましたら、お気軽にご相談ください。 ZooKeeper は分散構成センターとして使用でき、マイクロサービスの登録にも使用できます。ただし、マイクロサービスには現在、独自のサービス検出セットがあります。 ZooKeeper を理解することで、テクノロジーを選択する際に適切な判断を下すことができます。 ZooKeeper の高可用性と最終的な一貫性も比較的安定しています。

この記事のコードアドレス: https://github.com/muxiaonong/ZooKeeper/tree/master/mxnzookeeper

<<: エッジデータファブリックとは何ですか? また、なぜ重要ですか?

>>: HarmonyOSが配布するTikTok風アプリ